Message Rerouting and the Unreachable Queue
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
This topic describes Microsoft Exchange Server 2007 message routing scenarios where a message that is not delivered is put in the Unreachable queue for one of the following reasons:
A routing path could not be determined.
The message is rerouted.
When you track message flow or monitor transport message queues by using the Queue Viewer, it helps to understand under what conditions messages are put in the Unreachable queue or are rerouted. When a message is rerouted, it is resubmitted to the submission queue to determine the current least cost routing path. The categorizer determines the routing path.
Note
The decision to put a message in the Unreachable queue is made during the routing phase of categorization. If a routing path cannot 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 SMTP Send. If there are configuration changes that require a message in the queue to be resubmitted, the message is resubmitted for recategorization 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 Active Directory Site-Based Routing. For more information about how the categorizer works, see Transport Architecture.
Exchange 2007 transport servers detect configuration changes that may modify how a message is routed. For more information about how messages are routed in an Exchange 2007 organization by using Active Directory-based site routing, see Understanding Active Directory Site-Based Routing. For more information how to troubleshoot mail flow problems by using the Queue Viewer and other tools, see the following topics:
Troubleshooting Outbound Mail That is Put in the Unreachable Queue on the Hub Transport Server
The Exchange 2007 Wiki: Troubleshooting Exchange 2007 Transport Queuing Problems
Note
The content of Wikis and blogs and their URLs are subject to change without notice.
Scenarios Where Rerouting Occurs
Remote delivery queues are the main focus of message rerouting. Local delivery refers to delivery of messages that are sent to a recipient with a mailbox in the same Active Directory directory service site as the Hub Transport server on which categorization occurred. Remote delivery refers to delivery of messages to recipients in the Exchange organization and to external recipients. Remote delivery includes routing to remote Active Directory sites, to legacy routing groups, and to remote domains. 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. Enhanced DNS is a component of the Microsoft Exchange Transport service. During enhanced DNS resolution, the next hop selection is resolved to a list of target server names. The next hop is a property stamped as the NextHopSolutionKey attribute on the message during categorization. The routing component of the message categorizer tries to detect any configuration changes that require resubmission of the messages in the queue.
The store driver is a Hub Transport server component that delivers inbound messages to the Exchange databases. The store driver resubmits the message for rerouting if either of the following conditions is true:
A message is in a MAPI delivery queue, and the next hop has been selected. But the message has not yet 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, that is, a queue that is being routed to 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 drop directories that are configured for use by foreign connectors. For example, the deleting or disabling a foreign connector requires rerouting messages to another connector.
Several types of configuration changes affect message routing. There is an explanation later in this section of how these changes are handled by the Microsoft Exchange Transport service and how these changes affect message delivery. The following list summarizes the types of configuration changes:
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.
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 causes 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 does not change. An example is when the Hub Transport servers in an Active Directory site are offline.
Special cases In some cases, configuration changes may be caused when DNS MX resolution fails for a DNS connector or a smart host connector.
See the Table Configuration changes that cause message rerouting and delay later in this topic for a complete list of specific configuration changes that affect message routing.
Invalid Next Hops
This section describes the configuration changes that 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 that is 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 recategorized.
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 recategorized.
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 that were routed through that Send connector are rerouted.
SMTP Relay in an Active Directory Site
Simple Mail Transfer Protocol (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 2007 Hub Transport server that is 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 2007 Edge Transport server that is subscribed to the local Active Directory site.
The recipient's mailbox is located on a server that runs Microsoft Exchange Server 2003 and at least one of the source servers for the selected routing group connector is an Exchange 2007 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 2007 Hub Transport server in the local Active Directory site.
In the first three 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 fourth 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 that is 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 2007 server in a remote Active Directory site.
The recipient is an external address and the source servers of the Send connector that are selected for that address are Exchange 2007 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 2007 servers in a remote Active Directory site.
The recipient is a distribution group and the expansion server is an Exchange 2007 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 that is 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 2007 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 that is located on an Exchange 2003 server.
The recipient is an external address. And the source servers for the SMTP connector that are 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 Hops
In some scenarios, the next hop is not invalidated. However, it is modified in a way that affects the connection to a next hop target. Such configuration changes are automatically picked up 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
Changes to the list of smart hosts on a smart host connector
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 that is 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 are delivered along the previously calculated routing path. The following configuration changes fall into 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. If the connector whose scope is changed, from global to scoped, for example, is in the local Active Directory site, the change has no effect. If the connector is in remote Active Directory site, the change is not 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 is no longer an expansion server.
In these scenarios, the messages are delivered along the already calculated routing path. Because the routing path exists and is reachable, messages that are already routed are unaffected by these configuration changes. However, newly submitted messages are routed by using the updated configuration.
Unavailable Next Hops
In this scenario, a configuration change or network connectivity change does not 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 cannot be established to the next hop target for some reason. Possible reasons are as follows:
An attempt is made to establish 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 or Microsoft Exchange 2000 Server bridgehead servers.
Remote domains are unavailable because of network connectivity issues.
Message delivery failures that are caused by network connectivity problems are not detected by the routing component of the categorizer. When an SMTP connection cannot be established to the next hop target, SMTP Send 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 auto resubmission from the message delivery queue to the Submission queue only happens for non-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 was not found, an NDR for the messages in the queue is sent immediately. If other types of failures exist, the queue is put into retry until a connection is established or the messages expire.
DNS MX resolution fails for a smart host connector. The queue is put into retry until the messages expire.
Configuration Changes That Cause Message Rerouting or Delay
The following table summarizes the routing actions that are 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 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
Each transport server can have only one Unreachable queue. The Unreachable queue contains messages that cannot be routed to their destinations. Typically, an unreachable destination is caused by configuration changes that have modified the routing path for delivery. Regardless of destination, all messages that have unreachable recipients reside in this queue. For more information about queues, see Managing Queues.
As explained earlier in this topic, the decision to put a message in the Unreachable queue is made during the routing phase of categorization. If a routing path cannot 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 2007 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 cannot be calculated for that recipient.
The recipient is an external SMTP address and a matching connector cannot be found for the address space. A matching connector may also be ignored by the routing component of the categorizer because it is disabled or misconfigured.
The recipient is a distribution group. And the expansion server for the distribution group is invalid or does not have the Hub Transport server role installed.
The recipient is an SMTP address recipient of a message that was received on a Receive connector that is linked to a Send connector that is ignored by the routing component of the categorizer because it is disabled or misconfigured in some way.
In the following scenarios, messages are not put in the Unreachable queue. NDRs are sent instead.
The routing path cannot 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 cannot be found. Or the matching connector is disabled or misconfigured.
The recipient is a non-SMTP address recipient that was received on a Receive connector that is linked to a Send connector that is ignored by the routing component of the categorizer because the Send connector is disabled or misconfigured.
The decision to reroute a message occurs after categorization and during the message delivery phase. The decision to queue a message to the Unreachable queue is made in the routing phase of categorization. A rerouted message may be put in the Unreachable queue if configuration changes invalidate the determined routing path. You can see Unreachable queues in the Queue Viewer marked with the delivery type of Unreachable. For more information about how to troubleshoot the Unreachable queue and other mail flow problems, see the following topics:
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 are not the same.
Scenarios Where Messages Are Put in the Unreachable Queue
This section describes some scenarios where messages are put in the Unreachable queue.
- A routing group connector between an Exchange 2007 organization and Exchange 2003 organization does not exist.
A routing group connector between the Exchange 2007 routing group and Exchange 2003 routing groups has not been configured, or the last routing group connector between the Exchange 2007 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, verify that a routing group connector doesn't exist before you define a new routing group connector using the New-RoutingGroupConnector cmdlet. For more information, see How to Create Routing Group Connectors from Exchange 2007 to Exchange Server 2003 and New-RoutingGroupConnector. If a routing group connector does exist, the message is in the Unreachable queue for some other reason. For more information about how routing group connectors coexist, see "Creating Additional Routing Group Connectors" in Message Routing in a Coexistence Environment.
- The destination Active Directory site does not 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 Hub Transport Server Role: Overview.
- An 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 2007 servers. To resolve this problem, create a new 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 the administrator determine the configuration error and make corrections so that messages in the Unreachable queue can be routed successfully.An administrator can also manually cause messages in queues to be resubmitted. Use the Retry-Queue cmdlet with the Resubmit parameter to cause messages in a queue to be manually resubmitted to the categorizer. For more information, see How to Resubmit Messages in Queues.
For More Information
For more information, see the following topics: