Message Rerouting and the Unreachable Queue
Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2
In Microsoft Exchange Server 2010, there are message routing scenarios where a message that isn't delivered is put in the Unreachable queue or rerouted.
The decision to put a message in the Unreachable queue is made during the routing phase of categorization. If a routing path can't be calculated for a message during the routing phase, the message is sent to the Unreachable queue.
The decision to reroute a message occurs during the message delivery phase in the SMTP Send connector process. If there are configuration changes that require a message in the queue to be resubmitted, the message is resubmitted for categorization in the message delivery phase and rerouted with the new configuration information. Depending on the type of configuration change, some or all resubmitted messages may be sent to the Unreachable queue or to a different delivery queue.
For more information about how the least-cost routing path is computed, see Understanding Message Routing. For more information about how the categorizer works, see Understanding Transport Pipeline.
Looking for management tasks related to message routing? See Managing Message Routing.
Message Rerouting
There are two types of message delivery in Exchange:
Local delivery refers to delivery of messages sent to a recipient with a mailbox in the same Active Directory site as the Hub Transport server on which categorization occurred.
Remote delivery refers to delivery of messages to recipients in other Active Directory sites of the Exchange organization and to external recipients. Remote delivery queues are the main focus of message rerouting. Remote delivery can be affected by configuration changes in various ways.
The routing component of the categorizer tries to detect whether messages in a queue must be rerouted during enhanced Domain Name System (DNS) resolution. During enhanced DNS resolution, routing tries to detect if a queue has to be rerouted. In this phase, the NextHopSolutionKey attribute is resolved to a list of targets. This enables routing to automatically detect any configuration changes that invalidate or modify the NextHopSolutionKey attribute. If routing detects that configuration changes require rerouting of messages in a queue, the messages in the affected queue are resubmitted to the categorizer and the least cost path is recalculated, taking the new configuration changes into account.
The store driver, which delivers inbound messages to the Exchange databases, may also reroute messages. It resubmits a message for rerouting if either of the following conditions is true:
The message is in a MAPI delivery queue, and the next hop has been selected, but the message hasn't been delivered.
The destination mailbox is moved to another Mailbox server.
If a Mailbox server is unavailable when the store driver tries to deliver the messages to that Mailbox server, the store driver puts the message queue in a retry state. If continued attempts to contact the Mailbox server are unsuccessful, when the retry interval expires, all messages in the queue are resubmitted to the categorizer.
If a message is located in a non-SMTP gateway delivery queue (a queue being routed to a Delivery Agent connector or a Foreign connector), the foreign gateway connection handler determines whether the configuration change requires rerouting. The foreign gateway connection handler is a component of the Microsoft Exchange Transport service that manages delivery of messages to Delivery Agent connector queues and Foreign connector Drop directories. For example, deleting or disabling a Foreign connector requires rerouting messages to another connector.
The following list summarizes the types of configuration changes that affect message routing. Each configuration change is discussed in detail later in this topic:
Invalid next hop The next hop for the message has been deleted or modified, therefore invalidating the previously calculated routing path. The next hop for a message may be an Active Directory site, a connector, or a transport server (either a Hub Transport server or Edge Transport server).
Changes to next hop The configuration of the next hop has changed in a way that affects connectivity. For example, changes to the list of Hub Transport servers in the remote Active Directory site cause the next hop connection to be modified.
Less preferred routing paths When configuration changes occur along a previously computed routing path, messages already routed are delivered if the routing path is reachable. But new messages are rerouted with the updated configuration changes.
Unavailable next hop Network connectivity or target server availability cause the next hop to be unavailable for connectivity. However, the next hop doesn't change. An example is when the Hub Transport servers in an Active Directory site are offline.
Additional scenarios where rerouting occurs In some cases, configuration changes may be caused when DNS MX resource record resolution fails for a DNS connector or a smart host connector.
Configuration changes that cause message rerouting or delay When specific configuration changes are detected during the message delivery phase, routing actions occur, and messages are rerouted or delivery is delayed.
Invalid Next Hop
Configuration changes can invalidate a previously calculated next hop. In these circumstances, the routing component of the categorizer can detect the configuration change and reroute to compensate for that change.
Delivery to an SMTP Connector on the Local Computer
When a message is being delivered to an SMTP connector on the local computer, the server that received the message for relay to its destination is also the source server for the Send connector through which the message is routed. This kind of delivery occurs when either of the following conditions is true:
The message was received on a linked Receive connector.
The recipient has an external address, and a source server for the selected connector is the local computer.
If the Send connector selected by the routing component of the categorizer is deleted or disabled, the configuration change is detected during the message delivery phase. This causes all messages in the queue to be categorized again.
If the configuration of the Send connector is changed to remove the local server as a source server of the connector, the configuration change is detected during the message delivery phase, and all messages in the queue are categorized again.
A change of the address resolution method of the Send connector causes the queue to be rerouted. A Send connector can be configured to use DNS to resolve MX records and route messages automatically or it can be configured to route all messages through one or more smart hosts. If you change the address resolution of a Send connector, the messages routed through that Send connector are rerouted.
SMTP Relay in an Active Directory Site
SMTP message relay in an Active Directory site occurs in the following scenarios:
The recipient has an external address, and at least one of the source servers for the Send connector is an Exchange 2010 Hub Transport server located in the local Active Directory site.
The recipient has an external address, and at least one of the source servers for the Send connector is an Exchange 2010 Edge Transport server subscribed to the local Active Directory site.
The recipient's mailbox is located on a server that runs Exchange Server 2007 in the local Active Directory site.
The recipient's mailbox is located on a server that runs Exchange Server 2003, and at least one of the source servers for the selected routing group connector is an Exchange 2010 Hub Transport server in the local Active Directory site.
The recipient is a distribution group, and the expansion server for the group is an Exchange 2010 Hub Transport server in the local Active Directory site.
In the first four scenarios, if the Send connector is deleted or disabled, the configuration change is detected during the message delivery phase, and the queue is resubmitted.
In the last scenario, the messages are queued for delivery to an expansion server and the NextHopSolutionKey attribute contains the fully qualified domain name (FQDN) of the expansion server for the distribution group. If the Hub Transport server role is uninstalled from the specified expansion server, that configuration change is detected during the message delivery phase, and the queue is resubmitted.
SMTP Relay to a Remote Active Directory Site
When a message is being delivered to a remote Active Directory site, the next hop is a different Active Directory site than the Hub Transport server processing the message. This kind of delivery occurs in the following scenarios:
The recipient is a resolved user, mailbox database, or public folder, and the destination computer is an Exchange 2010 server in a remote Active Directory site.
The recipient is an external address, and the source servers of the Send connector selected for that address are Exchange 2010 servers in a remote Active Directory site.
The recipient is an external address, and the source servers of the Foreign connector selected by the routing component of the categorizer are Exchange 2010 servers in a remote Active Directory site.
The recipient is a distribution group, and the expansion server is an Exchange 2010 Hub Transport server in a remote Active Directory site.
The recipient's mailbox is located on an Exchange 2003 server, and the closest Hub Transport server listed as a source server for the selected routing group connector is located in a remote Active Directory site.
In these scenarios, if the remote Active Directory site is deleted, the configuration change is detected during the message delivery phase, and the queue is resubmitted.
SMTP Relay to an Exchange 2003 Server
When a message is being delivered to an Exchange 2003 server, the Exchange 2010 Hub Transport server relays the message through a routing group connector to an Exchange 2003 server. This delivery type occurs in the following scenarios:
The recipient is a resolved user, mailbox database, or public folder located on an Exchange 2003 server.
The recipient is an external address, and the source servers for the SMTP connector selected for that address are Exchange 2003 servers.
The recipient is an external address, and the source servers for the selected Foreign connector for that address are Exchange 2003 servers.
The recipient is a distribution group, and the designated expansion server is an Exchange 2003 server.
In these scenarios, if the routing group connector is deleted, the configuration change is detected during the message delivery phase, and the queue is resubmitted.
Changes to Next Hop
In some scenarios, the next hop isn't invalidated. However, it's modified in a way that affects the connection to a next hop target. Such configuration changes are automatically detected during the message delivery phase, and messages are delivered to the new targets.
The following types of changes cause an update of the list of next hop targets:
Changes to the target server list of a routing group connector.
Changes to the list of Hub Transport servers in the remote Active Directory site.
Changes to the list of Hub Transport servers or Edge Transport servers in the local Active Directory site.
The introduction of hub sites along a previously calculated routing path. When this change is detected during the message delivery phase, the IP address list returned to the resolve request is adjusted so that the message is sent to the hub site.
Less Preferred Routing Paths
If a configuration change causes the previously calculated routing path to become less preferred or removes the routing path from consideration, the routing path is still reachable and the messages can still be delivered along the previously calculated routing path. The following configuration changes are in this category:
Message size restrictions are added along the routing path. This causes messages that exceed the size limit to be routed along a different routing path.
A routing path with better cost or proximity is created.
The address space of the connector changes.
Other connector-related changes occur, such as the enabling of a connector or modification of the scope for a connector. For example, if a connector whose scope is changed from global to scoped is in the local Active Directory site, the change has no effect. If the connector is in a remote Active Directory site, the change isn't detected during the message delivery phase because the messages are queued to the remote Active Directory site instead of to the connector.
As the routing path tries to SMTP-relay to a Mailbox server in the remote Active Directory site, the Mailbox server moves from a remote Active Directory site to a local Active Directory site.
The routing path is trying to reach the expansion server for a distribution group when it's no longer an expansion server.
In these scenarios, existing messages are delivered along the already calculated routing path. Because the routing path exists and is reachable, messages already routed are unaffected by these configuration changes. However, newly submitted messages are routed by using the updated configuration.
Unavailable Next Hop
In this scenario, a configuration change or network connectivity change doesn't invalidate the next hop to which messages are routed but a configuration change or network connectivity change makes the next hop unavailable. This means that an SMTP connection can't be established to the next hop target for some reason. Possible reasons are as follows:
An attempt is made to establish an SMTP connection with a currently offline Hub Transport server in the local site.
A remote Active Directory site has unavailable or offline Hub Transport servers.
A remote routing group has unavailable or offline Exchange 2003 bridgehead servers.
Remote domains are unavailable because of network connectivity issues.
Message delivery failures caused by network connectivity problems aren't detected by the routing component of the categorizer. When an SMTP connection can't be established to the next hop target, the SMTP Send connector retries the queue. The MaxIdleTimeBeforeResubmit parameter, which is located in the EdgeTransport.exe.config file, has a default value of 12 hours. After the configurable retry interval (MaxIdleTimeBeforeResubmit) has expired without successfully establishing a connection, all messages from the delivery queue are resubmitted to the Submission queue. If the connectivity problem still exists, this process is repeated. If the connectivity problem is resolved, messages are delivered as soon as message retry is successful. Or, a configuration change that modifies the next hop destination may resolve the problem. For example, if the problem is caused by all the Hub Transport servers in a destination site being offline, and you move mailboxes to a server in a different site, the next hop would change to the new site.
Note
The automatic resubmission from the message delivery queue to the Submission queue only happens for queues that aren't connector queues. Connector queues remain in retry mode until the problem is fixed, or the messages expire and a non-delivery report (NDR) is sent.
Additional Scenarios Where Rerouting Occurs
In addition to the scenarios described earlier in this section, the following scenarios cause messages to be rerouted during the message delivery phase:
DNS MX resolution fails for a DNS connector. If the DNS MX resolution fails because the authoritative host for the MX record wasn't found, an NDR for the messages in the queue is sent immediately. If other types of failures exist, the queue is put into retry mode until a connection is established or the messages expire.
DNS MX resolution fails for a smart host connector. The queue is put into retry mode until the messages expire.
Configuration Changes That Cause Message Rerouting or Delay
The following table summarizes the routing actions taken when specific configuration changes are detected during the message delivery phase, and messages are rerouted or delivery is delayed.
Configuration changes that cause message rerouting and delay
| Routing scenario | Configuration change and routing action | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Message is routed to a DNS connector configured on the local server. |
|
||||||||||||||||
Message is routed to a smart host connector configured on the local server. |
|
||||||||||||||||
Message is routed to a connector with a source Hub Transport server or Edge Transport server in the local Active Directory site. |
|
||||||||||||||||
Message is routed to an expansion server for a distribution group in the local Active Directory site. |
|
||||||||||||||||
Message is routed to a transport server in the local Active Directory site. |
|
||||||||||||||||
Message is routed to a remote Active Directory site. |
|
||||||||||||||||
The message is routed to an Exchange 2003 server in a remote routing group. |
|
||||||||||||||||
The message is routed to a destination, and there are configuration changes, but the destination is still reachable. |
|
||||||||||||||||
The message is routed by using MAPI delivery to a Mailbox server. |
|
||||||||||||||||
The message is routed by using a non-SMTP gateway to a non-SMTP connector configured on the local server. |
|
Unreachable Queue
The Unreachable queue contains messages that can't be routed to their destinations. Typically, an unreachable destination is caused by misspelled e-mail addresses, or configuration changes that have modified the routing path for delivery. Regardless of destination, all messages that have unreachable recipients reside in this queue.
The decision to put a message in the Unreachable queue is made during the routing phase of categorization. If a routing path can't be calculated for a message during the routing phase, the message is sent to the Unreachable queue. Messages in the Unreachable queue are rerouted after configuration changes are processed. There is only one Unreachable queue for each Exchange 2010 transport server.
During categorization, messages are put in the Unreachable queue when the following conditions are true:
The recipient is a valid Active Directory recipient object. However, a routing path can't be calculated for that recipient.
The recipient is an external SMTP address and a matching connector can't be found for the address space. A matching connector may also be ignored by the routing component of the categorizer because it's disabled or configured incorrectly.
The recipient is a distribution group. The expansion server for the distribution group is invalid or doesn't have the Hub Transport server role installed.
The recipient is an SMTP address recipient of a message received on a Receive connector linked to a Send connector that's ignored by the routing component of the categorizer because it's disabled or configured incorrectly in some way.
In the following scenarios, messages aren't put in the Unreachable queue, and NDRs are sent instead:
The routing path can't be calculated for a recipient because constraints, such as message size restrictions, prevent delivery of the message using the single, deterministic route calculated by the categorizer.
The recipient is a non-SMTP address and a matching connector can't be found. Or the matching connector is disabled or configured incorrectly.
The recipient is a non-SMTP address recipient received on a Receive connector linked to a Send connector that's ignored by the routing component of the categorizer because the Send connector is disabled or configured incorrectly.
Messages in the Unreachable queue are resubmitted to the categorizer when the routing tables are rebuilt because of configuration changes. The old routing tables and new routing tables are compared. The Unreachable queue is resubmitted only if the old routing tables and new routing tables aren't the same.
Scenarios Where Messages Are Put in the Unreachable Queue
This section describes some scenarios where messages are put in the Unreachable queue.
- Routing group connector between an Exchange 2010 organization and Exchange 2003 organization doesn't exist
A routing group connector between the Exchange 2010 routing group and Exchange 2003 routing groups hasn't been configured, or the last routing group connector between the Exchange 2010 routing group and Exchange 2003 routing groups has been removed. No routing group connector exists to provide a routing path to the Exchange 2003 recipients. To resolve this problem, first verify that the routing group connector is missing. If that's the case, you can create a routing group connector. For more information, see Create Additional Routing Group Connectors from Exchange 2010 to Exchange 2003. If a routing group connector does exist, the message is in the Unreachable queue for some other reason. Check the configuration of the routing group connector.
- Destination Active Directory site doesn't have Hub Transport servers
The destination Active Directory site has no Hub Transport servers. In this scenario, messages to recipients in that site are sent to the Unreachable queue. To resolve this problem, deploy a Hub Transport server in the Active Directory site. For more information, see Overview of the Hub Transport Server Role.
- Active Directory site link doesn't exist between two Active Directory sites
An Active Directory site link has been removed and as a result, a disconnected Active Directory site contains Exchange 2010 servers. To resolve this problem, create an Active Directory site link by using Active Directory Sites and Services.
Other issues
When a message is put in the Unreachable queue, the last error message specifies why the message was placed in the Unreachable queue. If more than one recipient of the same message is routed to the Unreachable queue, but for different reasons, the last error available on each recipient specifies the reason for each. When inconsistencies are found during routing table computation, events are logged in the Application log of Windows Event Viewer. The last error message and these events can help you determine the configuration error and make corrections so that messages in the Unreachable queue can be routed successfully.You can also manually force the messages in queues to be resubmitted. For more information, see Resubmit Messages in Queues.
© 2010 Microsoft Corporation. All rights reserved.