Working with the Queue Database on Transport Servers

Artykuł
01/23/2017

Microsoft Exchange Server 2007 will reach end of support on April 11, 2017. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.

Applies to: Exchange Server 2007, Exchange Server 2007 SP1, Exchange Server 2007 SP2, Exchange Server 2007 SP3

A queue is a temporary holding location for messages that are waiting to enter the next stage of processing. Each queue represents a logical set of messages that an Exchange transport server processes in a specific order. Queues exist only on computers that have the Hub Transport server role or Edge Transport server role installed.

Microsoft Exchange Server 2007 uses a single Extensible Storage Engine (ESE) database for queue message storage. Formerly known as JET, ESE is a method that defines a low-level API to the underlying database structures in Exchange Server.

The following scenarios may result in an unresponsive Hub Transport server or Edge Transport server that has a queue database that contains undelivered messages:

An Exchange transport server fails when there are undelivered messages in the queues. Additionally, you can't bring the server back online in a timely manner.
An Exchange transport server has a fragmented queue database that grows so large that it consumes all available hard disk drive space.

You can move the queue database and its associated transaction log files to a temporary location on a target Exchange transport server, repair the queue database, replace the existing queue database on the target Exchange transport server, and then start the repaired queue database on the target Exchange transport server. This target Exchange transport server can be in your Exchange organization or in a different Active Directory directory service forest.

Before You Begin

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.

Recovering a Queue Database on the Target Exchange Transport Server

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

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

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

By default, the queue database and the transaction logs are located in C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue. The queue database location and the transaction log location are configured in the EdgeTransport.exe.config application configuration file that is located in C:\Program Files\Microsoft\Exchange Server\Bin. The QueueDatabasePath parameter controls the location of the database files, and the QueueDatabaseLoggingPath parameter controls the location of the transaction logs.

The queue database consists of the following files:

Mail.que The queue database file.
Trn.chk The checkpoint file.

The transaction log consists of the following files:

Trn.log The current transaction log file.
Trntmp.log The next provisioned transaction log file that is created in advance.
Trnnnn.log Other transaction log files that are created when Trn.log reaches its maximum size as specified by the QueueDatabaeLoggingFileSize parameter in the EdgeTransport.exe.config application configuration file. The default is 5 MB.
Trnres00001.jrs The placeholder log file.
Trnres00002.jrs The placeholder log file.
Temp.edb Although not a transaction log file, this queue database schema verifier file is located with the transaction log files.

To move the queue database to the Hub Transport server or Edge Transport server

Stop the Microsoft Exchange Transport service on the Exchange transport server that has the affected queue database.
- Type the following command at a command prompt or in the Exchange Management Shell:
```
Net Stop MSExchangeTransport
```
Move all the queue database and transaction log files to a temporary directory on the target Hub Transport server or Edge Transport server. For the purposes of this example, that directory will be: C:\QueueRecovery.
After the affected Exchange 2007 transport server is fixed, a new queue database is created when the Microsoft Exchange Transport service is restarted. This can occur at any time after you have finished copying the queue database files to the target transport server.

For more information about the queue database files, see Managing the Queue Database.

Performing a Recovery of the Queue Database by Using Eseutil

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

At a command prompt or in the Exchange Management Shell, open the C:\QueueRecovery directory.
Run the following command:
```
Eseutil /r Trn /d. /8
```
Trn indicates the 3-character log base file name. /8 sets an 8-kilobyte database page size for faster recovery. /d. indicates the database to recover exists in the current directory.

Note

Database recovery may take a long time for a large queue database.

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

Perform an Offline Defragmentation of the Queue Database by Using Eseutil

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

At a command prompt or in the Exchange Management Shell, open the C:\QueueRecovery directory.
Run the following command:
```
Eseutil /d mail.que
```
Note

Offline database defragmentation may take a long time for a large queue database

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:

Stop the flow of new messages into the queues and allow the existing messages to be delivered.
Monitor the mailbox delivery queues and remote delivery queues until all messages have been delivered.
Resubmit, or suspend and export any messages in the Unreachable queue that you want to save.
Resume or export any messages in the poison message queues that you want to save.
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:
```
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

To resubmit messages that exist in the Unreachable queue, run the following command in the Exchange Management Shell on the target Exchange transport server:
```
Retry-Queue -Identity "Unreachable" -Resubmit $True
```
Use the Queue Viewer to suspend any messages that you want to export from the Unreachable queue.
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:
```
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

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:
```
Get-Message -Queue "Poison" | ft Identity
Resume-Message <IdentityofPoisonMessage>
```
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:
```
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:
```
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

To start the recovered queue database on the target Exchange transport server

At a command prompt or in the Exchange Management Shell, run the following command on the target Exchange transport server:
```
Net Stop MSExchangeTransport
```
Overwrite all the existing empty queue database files and transaction log files on the target Exchange transport server by using all the files from "C:\QueueRecovery". By default, the queue database and transaction logs exist in C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue.
At a command prompt or in the Exchange Management Shell, run the following command:
```
Net Start MSExchangeTransport
```

Post-Recovery Configuration Tasks

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

For more information, see the following topics:

Udostępnij za pośrednictwem