To perform the following procedures, the account you use must be delegated the following:

• Exchange Server Administrator role
  
  

To perform the following procedures on a computer that has the Edge Transport server role installed, you must log on by using an account that is a member of the local Administrators group on that computer.

For more information about permissions, delegating roles, and the rights that are required to administer Microsoft Exchange Server 2007, see Permission Considerations.

As you perform tasks on the queue database and its associated files, for example, move the queue database to the target server or perform offline repair and defragmentation, make sure that you have the permissions in the following list in the directory where the queue database exists:

• Network Service: Full Control
  
  
• System: Full Control
  
  
• Administrators: Full Control
  
  

The target Exchange transport server that you select to receive the recovered queue database should have the same Exchange 2007 service packs and security updates installed as the source Exchange server.

If you can do this, you should select a target Exchange transport server to receive the recovered queue database that has the same transport server role as the source server. You may experience unexpected message delivery behavior if either of the following conditions is true:

• You start the recovered queue database on an Exchange transport server that has a different server role than the source server.
  
  
• You start the recovered queue database on an Exchange transport server that is located in a different Active Directory forest.
  
  

For example, messages that are awaiting delivery in a Mailbox Delivery queue may now require delivery by using a Remote Delivery queue. Formerly remote addresses may now be local, and formerly local addresses may be remote. Be prepared for messages to appear in the Unreachable queue. You may have to manually resubmit messages back through the categorizer. For information, see How to Resubmit Messages in Queues.

The basic steps of the queue database recovery are as follows:

1. Move the queue database to a temporary location on the target Exchange transport server.
   
   
2. Perform a recovery of the queue database by using Exchange Server Database Utilities (Eseutil.exe).
   
   
3. Perform an offline defragmentation of the queue database by using Eseutil.
   
   
4. Prepare the existing queue database on the target Exchange transport server for replacement by the recovered queue database.
   
   
5. Start the repaired queue database on the target Exchange transport server.
   
   

Moving the Queue Database to a Temporary Location on the Target Transport Server

Before you try to start the queue database on the target transport server, you should use Eseutil to perform a database recovery. Because the queue database uses circular logging, you cannot replay old transaction logs into the database by using Eseutil /C restore mode. However, you can perform a database recovery by using Eseutil /R recovery mode. You can use Eseutil for offline queue database maintenance and repair.

Note:
Eseutil is located in C:\Program Files\Microsoft\Exchange Server\Bin. This directory is defined in the path. Therefore, you can type the command without specifying the full path.

The recovery process reads the checkpoint file and commits the uncommitted transactions in the transaction log to the queue database. If no checkpoint file exists, replay starts with the oldest log file entry that is available in the transaction log.

To perform a queue database recover using Eseutil

For more information about how to use Eseutil for database recovery, see Eseutil /R Recovery Mode.

After you have performed a recovery of the queue database, it is a good idea to also run an offline defragmentation on the database by using Eseutil /D defragmentation mode for the general health and performance of the queue database. An offline defragmentation of an ESE database reclaims the empty database white space and can reduce the size of the database files.

To perform an offline defragmentation of the queue database by using Eseutil

For more information about how to use Eseutil for offline database defragmentation, see Eseutil /D Defragmentation Mode.

Preparing the Existing Queue Database on the Target Exchange Transport Server for Replacement by the Recovered Queue Database

You could overwrite the queue database on the target Exchange transport server by using the recovered queue database. However, that would eliminate all existing messages in the queues on the target Exchange transport server. To safely start the recovered queue database, you must first follow these steps on the target Exchange transport server:

1. Stop the flow of new messages into the queues and allow the existing messages to be delivered.
   
   
2. Monitor the mailbox delivery queues and remote delivery queues until all messages have been delivered.
   
   
3. Resubmit, or suspend and export any messages in the Unreachable queue that you want to save.
   
   
4. Resume or export any messages in the poison message queues that you want to save.
   
   
5. Modify the message expiration time-out on the Exchange transport server so the messages in the recovered queue database are preserved.
   
   

To stop the flow of new messages into the queues on the target Exchange transport server and allow the existing messages to be delivered

• At a command prompt or in the Exchange Management Shell, run the following command:

  	Copy Code
  Net Pause MSExchangeTransport

To monitor the mailbox delivery queues and remote delivery queues on the target Exchange transport server until all messages have been delivered

• Use the Queue Viewer or the Get-Queue cmdlet in the Exchange Management Shell to monitor the delivery queues on the target Exchange transport server. Wait until no messages remain in any of delivery queues on the server as indicated by a message count of 0.

To resubmit, or suspend and export any messages in the Unreachable queue on the target Exchange transport server that you want to save

1. To resubmit messages that exist in the Unreachable queue, run the following command in the Exchange Management Shell on the target Exchange transport server:

   	Copy Code
   Retry-Queue -Identity "Unreachable" -Resubmit $True

2. Use the Queue Viewer to suspend any messages that you want to export from the Unreachable queue.

3. To export all the suspended messages from the Unreachable queue to a directory, with automatic message file naming using the format InternalMessageID.eml, run the following command in the Exchange Management Shell:

   	Copy Code
   Get-Message -Queue "Unreachable" | Export-Message -Path "<ExistingLocalDirectory>"

For more information about how to resubmit messages, see How to Resubmit Messages in Queues.

For more information about how to suspend messages, see How to Suspend Messages.

For more information about how to export messages, see How to Export Messages from Queues.

To resume or export any messages in the poison message queue on the target Exchange transport server that you want to save

1. To resume the messages in the poison message queue, perform one of the following steps:

   • In the Queue Viewer, select the Poison Message queue, select a message, and, in the action pane, select Resume.
     
     
   • In the Exchange Management Shell, run the following commands:
     
     

     	Copy Code
     Get-Message -Queue "Poison" | ft Identity Resume-Message <IdentityofPoisonMessage>

2. To export all the suspended messages from the Poison Message queue to a directory, with automatic message file naming using the format InternalMessageID.eml, run the following command in the Exchange Management Shell:

   	Copy Code
   Get-Message -Queue "Poison" | Export-Message -Path "<ExistingLocalDirectory>"

Note:

The poison message queue contains messages that are determined to be harmful to the Exchange 2007 system after a server failure. The messages may be genuinely harmful in their content or format, or they may be victims of a poorly-written agent that caused the Exchange server to fail when it was processing the allegedly harmful messages. If you are unsure of the safety of the messages in the poison message queue, export the messages to files so that you can examine them. If you decide to remove messages from the poison message queue, remove them without sending a non-delivery report (NDR). The NDR may contain the content of the original message. Messages in the poison message queue are already in the suspended state. Therefore, you don't have to suspend them before they are exported. The poison message queue can't be resubmitted by using the Retry-Queue cmdlet with the Resubmit parameter. To resubmit the messages in the poison message queue, use the Queue Viewer to resume the messages, or use the Resume-Message cmdlet.

For more information about how to resume messages, see How to Resume Messages.

To modify the message expiration time-out on the target Exchange transport server so the messages in the recovered queue database are preserved

• Run the following command in the Exchange Management Shell:

  	Copy Code
  Set-TransportServer -MessageExpirationTimeout <LongerTimeOutIntervalIndd.hh:mm:ssFormat>

  By default, any undelivered message is returned to the sender with an NDR and deleted from the queue. If the either of the following conditions is true, you must increase the message expiration time-out interval:

  • The queue database that you are trying to recover has been offline for more than two days.
    
    
  • The queue database doesn't finish delivering messages within two days after it has been recovered.
    
    

  This prevents the messages from being deleted immediately after the queue database is started or as the restarted database delivers its old messages.

For more information about message expiration, see Managing Message Retry, Resubmit, and Expiration Intervals.

Starting the Repaired Queue Database on the Target Exchange Transport Server

When the recovered queue database is started on the target Exchange transport server, messages should start to flow. The following list describes potential issues that you may encounter:

• Be prepared to deal with messages in the poison message queue if the recovered queue database came from an Exchange 2007 server that has failed. You must decide for each message in the poison message queue if the message really did cause the Exchange 2007 server to fail or if the message was put in the poison message queue unnecessarily. You may decide to resume the message or export the message to examine it. If you are unsure of the safety of a message in the poison message queue, you should export the message to a file so that you can examine it. If you decide to remove messages from the poison message queue, remove them without sending an NDR. The NDR may contain the content of the poison message.
  
  
• Be prepared to deal with messages in the Unreachable queue and delivery queues that are stuck in the Retry state. You should manually resubmit these messages.
  
  
• If you decide to remove messages that have delivery problems, you must decide whether to send an NDR when you remove the messages. If you remove the messages and send an NDR, the NDR messages themselves require delivery. Moreover, they may themselves have their own delivery problems. You may decide to remove the problematic messages without sending an NDR. For more information about how to remove a message, see How to Remove Messages from Queues.
  
  
• You should consider whether to permanently keep the recovered queue database on the target Exchange transport server or to replace it with a new queue database after all the trapped messages have been delivered. As soon as you start the recovered queue database, new messages enter the queues as part of the regular message delivery activity of the Exchange transport server. If you decide to replace the queue database by using a fresh copy, you must follow these steps:
  
  
  1. Pause the Microsoft Exchange Transport service to let the existing messages drain completely. During this pause, no new messages will be accepted.
     
     
  2. Stop the Microsoft Exchange Transport service.
     
     
  3. Delete all the queue database files and transaction log files.
     
     
  4. Start the Microsoft Exchange Transport service.
     
     

For more information, see the following topics:

• Managing the Queue Database
  
  
• How to Remove Messages from Queues
  
  
• Eseutil