Managing Message Retry, Resubmit, and Expiration Intervals
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
Computers that are running Microsoft Exchange Server 2007 and that have the Hub Transport server role or Edge Transport server role installed contain queues, Send connectors, and Receive connectors. The queues hold the messages that must be delivered. The connectors establish the inbound or outbound paths to deliver the messages.
Messages that cannot be successfully delivered are subject to various retry, resubmit, and expiration deadlines based on the message's source and destination. Retry is a renewed connection attempt with the destination domain, smart host, or Mailbox server. Resubmit is the act of sending messages back to the Submission queue for the categorizer to reprocess. The message is said to "time-out" or expire after all delivery efforts have failed over a specified period of time. After a message expires, the sender is notified of the delivery failure. Then the message is deleted from the queue.
In all three cases of retry, resubmit, or expire, you can manually intervene before the automatic actions are performed on the messages.
Configuration Options for Message Retry
When a transport server cannot connect to the next hop, the queue is put in a status of Retry. Connection attempts continue until the queue expires or a connection is made.
Configuration Options for Automatic Message Retry
The configuration options that are available for message retry intervals are described in Table 1.
Table 1 Configuration options that are available for message retry intervals
| Parameter name | Default value | Where to configure | Description |
|---|---|---|---|
QueueGlitchRetryCount |
4 |
EdgeTransport.exe.config |
This parameter specifies the number of connection attempts that are immediately tried when a transport server has trouble connecting with the destination server. Such connection problems are typically caused by very brief network outages. Typically, you don't have to modify this parameter unless the network is unreliable and continues to experience many accidentally dropped connections. |
QueueGlitchRetryInterval |
1 minute |
EdgeTransport.exe.config |
This parameter controls the connection interval between each connection attempt that is specified by the QueueGlitchRetryCount parameter. Typically, you don't have to modify this parameter unless the network is unreliable and continues to experience many accidentally dropped connections. |
TransientFailureRetryCount |
6 |
Set-TransportServer cmdlet or transport server properties in the Exchange Management Shell |
This parameter specifies the number of connection attempts that are tried after the connection attempts that are controlled by the QueueGlitchRetryCount and QueueGlitchRetryInterval parameters have failed. Connection problems that exhaust the QueueGlitchRetry parameters can be caused by such things as server restarts or cached DNS lookup failures. |
TransientFailureRetryInterval |
|
Set-TransportServer cmdlet or transport server properties in the Exchange Management Shell |
This parameter controls the connection interval between each connection attempt that is specified by the TransientFailureRetryCount parameter. |
OutboundConnectionFailureRetryInterval |
|
Set-TransportServer cmdlet or transport server properties in the Exchange Management Shell |
This parameter specifies the retry interval for outbound connection attempts that have previously failed. The previously failed connection attempts are controlled by the TransientFailureRetryCount and TransientFailureRetryInterval parameters. |
MessageRetryInterval |
1 minute |
Set-TransportServer cmdlet |
This parameter specifies the retry interval for individual messages that have a status of Retry. We recommend that you don't modify the default value unless Microsoft Support Services advises you to do this. |
MailboxDeliveryQueueRetryInterval |
5 minutes |
EdgeTransport.exe.config |
This parameter controls the retry interval for mailbox delivery queues between Hub transport servers. |
The EdgeTransport.exe.config file is an XML application configuration file that is associated with the EdgeTransport.exe file. EdgeTransport.exe and MSExchangeTransport.exe are the executable files that are used by the Microsoft Exchange Transport service. This service runs on every Hub Transport server or Edge Transport server. Changes that are saved to the EdgeTransport.exe.config file are applied after the Microsoft Exchange Transport service is restarted.
The following is a basic example of the EdgeTransport.exe.config file structure:
<configuration>
<runtime>
<gcServer enabled="true" />
</runtime>
<appSettings>
<add key="ConfigurationOption" value="Value" />
...
</appSettings>
</configuration>
The <appSettings> section is where you can add new configuration options or modify existing configuration options. There are many configuration options available that are completely unrelated to the message retry, resubmit, and expiration intervals. Any configuration options that don't involve these intervals are outside the scope of this topic. They won't be discussed here.
Note
The parameter names in the <add key=../> section are case sensitive.
For more information, see How to Configure Message Retry, Resubmit, and Expiration Intervals.
Configuration Options for Manual Message Retry
When a mailbox delivery queue or a remote delivery queue is in the status of Retry, you can manually force an immediate connection attempt by using the Queue Viewer in the Exchange Management Console or the Retry-Queue cmdlet in the Exchange Management Shell. The manual retry attempt overrides the next scheduled retry time. If the connection is not successful, the retry interval timer is reset. The delivery queue must be in a status of Retry for this action to have any effect.
For more information, see How to Retry Queues.
Configuration Options for Delay DSN Notification Messages
After each message delivery failure, the Edge Transport server or the Hub Transport server generates a delay delivery status notification (DSN) message and queues it for delivery to the sender of the undeliverable message. This delay DSN message is sent only after a specified delay notification time-out interval, and only if the failed message wasn't successfully delivered during that time. By default, the delay notification time-out interval is 4 hours. This delay prevents the sending of unnecessary delay DSN messages that may be caused by temporary message transmission failures. The sending of delay DSN notification messages can be selectively enabled or disabled for messages that originate inside or outside the Exchange organization.
The configuration options that are available for delay DSN notification messages are described in Table 2.
Table 2 Configuration options that are available for delay DSN notification messages
| Parameter name | Default value | Location | Description |
|---|---|---|---|
DelayNotificationTimeOut |
4 hours |
Set-TransportServer |
This parameter specifies how long the server waits before it sends a delay DSN message to the message's sender. The value of this parameter should always be greater than the value of the TransientFailureRetryCount parameter multiplied by the value of the TransientFailureRetryInterval. |
ExternalDelayDSNEnabled |
|
Set-TransportServer |
This parameter specifies whether delay DSN messages can be sent to message senders who are outside the Exchange organization. |
InternalDelayDSNEnabled |
|
Set-TransportServer |
This parameter specifies whether delay DSN messages can be sent to message senders who are inside the Exchange organization. |
For more information, see How to Configure Message Retry, Resubmit, and Expiration Intervals.
Configuration Options for Message Resubmission
Message resubmission sends undelivered messages back to the Submission queue to be reprocessed by the categorizer.
Automatic Message Resubmission
Undelivered messages are automatically resubmitted if the delivery queue is in the status of Retry and has been unable to successfully deliver any messages for a specified period of time. That period of time is controlled by the MaxIdTimeBeforeResubmit parameter in the EdgeTransport.exe.config application configuration file. By default, the value of the MaxIdTimeBeforeResubmit parameter is 12 hours. Only messages in mailbox delivery queues or remote delivery queues are candidates for automatic resubmission.
For more information, see How to Configure Message Retry, Resubmit, and Expiration Intervals.
Manual Message Resubmission
You can manually resubmit messages that have the following status on a Hub Transport server or an Edge Transport server:
Mailbox delivery queues or remote delivery queues that have the status of Retry. The messages in the queues must not be in the Suspended state.
Messages that are in the Unreachable queue and are not in the Suspended state.
Messages that are in the poison message queue.
For more information about the poison message queue and the Unreachable queue, see "About the Poison Message Queue and the Unreachable Queue" later in this topic.
If you want to manually resubmit messages that are located in the mailbox delivery queues, the Remote Delivery queues, or the Unreachable queue without waiting for the time that is specified by the MaxIdleTimeBeforeResubmit parameter to pass, you must use the Retry-Queue cmdlet with the Resubmit parameter. To manually resubmit messages that are located in the poison message queue, you can use the Queue Viewer or the Resume-Message cmdlet to resume the message.
For more information, see the following topics:
Another way that you can manually resubmit messages is to suspend the messages, export the messages to text files that have the .eml file name extension, and then copy the .eml files to the Replay directory on any Hub Transport server or Edge Transport server. This resubmission method works for messages that are located in the mailbox delivery queues, remote delivery queues, or the Unreachable queue. Messages that are located in the poison message queue are already in the Suspended state. Messages that are located in the Submission queue cannot be suspended or exported.
Note
When you export messages from a queue, you do not remove the messages from the queue. After you export the messages and successfully resubmit them by using the Replay directory, you should remove the suspended messages to avoid duplicate message delivery.
For more information, see How to Export and Resubmit Messages.
Configuration Options for Message Expiration
The message expiration time-out interval specifies the maximum length of time that an Edge Transport server or a Hub Transport server tries to deliver a failed message. If the message cannot be successfully delivered before the expiration time-out interval has passed, a non-delivery report (NDR) that contains the original message or the message headers is delivered to the sender.
Automatic Message Expiration
The message expiration time-out interval is controlled by the MessageExpirationTimeOut parameter in the Set-TransportServer cmdlet or in the transport server properties in the Exchange Management Shell. By default, the value of the MessageExpirationTimeOut parameter is 2 days.
For more information, see the following topics:
Manual Message Expiration
Although you can't manually force messages to expire, you can manually remove messages from any queue, except the Submission queue, with or without an NDR.
For more information, see How to Remove Messages from Queues.
About the Poison Message Queue and the Unreachable Queue
The categorizer sends messages to the Unreachable queue when there is no known route to their destinations. Typically, an unreachable destination is caused by a configuration error that affects the delivery path. For example, the messages will be sent to the Unreachable queue if the following conditions are true:
There are messages in the "Contoso.com" remote delivery queue.
You delete the Send connector that is used to reach the Contoso.com domain.
By default, the messages in the Unreachable queue have the status of Ready. Messages in the Unreachable queue are never automatically resubmitted. Messages remain in the Unreachable queue until they are manually resubmitted by an administrator, removed by an administrator, or the value specified in the MessageExpirationTimeOut parameter passes.
The poison message queue contains messages that are determined to be potentially harmful to the Exchange 2007 server after a server failure. The messages may be genuinely harmful in their content and format. Alternatively, they may be the results of a poorly-written agent that has caused the Exchange server to fail when it processed the supposedly bad messages. All messages in the poison message queue are in a permanently suspended state. The poison message queue cannot be resubmitted with the Retry-Queue cmdlet with the Resubmit parameter. To resubmit the messages in the poison message queue, you can use the Queue Viewer or the Resume-Message cmdlet to resume the messages. The messages in the poison message queue are never automatically resumed or expired. Messages remain in the poison message queue until they are manually resumed or removed by an administrator.
For More Information
For more information about queues, see Managing Queues.