Understanding Message Routing

 

Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2

The primary task of Hub Transport and Edge Transport servers in your organization is to route messages received from users and external sources to their ultimate destinations. This topic explains how Microsoft Exchange Server 2010 routes messages in your organization.

Looking for management tasks related to managing transport servers? See Managing Transport Servers.

Contents

Overview of Message Routing in Exchange 2010

Routing Components

Using Active Directory Sites for Routing

Exchange 2010 Routing Tables

Receiving Messages for Routing

Routing Messages

Rerouting and the Unreachable Queue

Overview of Message Routing in Exchange 2010

Routing decisions are made during message categorization. The categorizer is a component of the Microsoft Exchange Transport service that processes all incoming messages and determines what to do with the messages based on information about the intended recipients. The categorizer processes messages in several dependent phases and also uses other components of the Microsoft Exchange Transport service during message processing. After a message is received by an Exchange 2010 transport server, and after the preliminary processing that occurs during SMTP Receive is complete, the message is delivered to the Submission queue. Messages move from the Submission queue through the categorizer in the following phases:

1. Agent processing of submitted messages   Some agent processing on the Hub Transport server occurs when the message is received for categorization. The agents that are applied during this phase include the optional Microsoft Forefront Protection for Exchange Server antivirus agent and the Journaling agent.

2. Recipient resolution   During this phase, the recipient's e-mail address is resolved to determine whether the recipient has a mailbox in the Exchange organization or an external e-mail address.

3. Routing   After information about the recipient is resolved, the routing component of the categorizer determines the ultimate destination for the message and the route to that destination, selects the next segment, or hop, for message relay, and resolves the next hop information to a list of physical servers and IP addresses.

4. Content conversion   Before a message is relayed to its next hop, content conversion occurs so that the message is sent in a format that's readable by the recipient. Content conversion transforms e-mail messages from one format to another format for mail flow or storage, such as MAPI to MIME, or UUENCODE to base64 encoded, or for appropriate rendering that's specific to an e-mail client, such as HTML, rich text format (RTF), or plain text.

5. Agent processing of routed messages   After the routing decisions for a particular message are made, the Transport Rules agent and the Journaling agent are applied on the Hub Transport server. The Journaling agent is applied both when the message is submitted and when it's routed so that any changes that are made to the message by the Transport Rules agent, for example, when it modifies a delivery address or applies a message-specific journaling requirement, don't bypass the Journaling agent.

6. Message packaging and DSN generation   The final categorized message is assembled and moved to a delivery queue. A delivery status notification (DSN) may also be generated during this phase.

Messages are next processed by SMTP Send, the store driver, delivery agents, or the foreign gateway connection handler. The component that's used depends on the ultimate destination. A delivery queue is dynamically generated for each hop. The messages are queued in these delivery queues after a routing decision is made. If a route can't be found for a recipient, the messages are queued to the Unreachable queue.

The following figure shows how message processing occurs in the different routing phases and how messages are queued for delivery to the next hop destination.

Routing context in mail flow

Return to top

Routing Components

To make routing decisions, Exchange 2010 must access configuration information that's stored in Active Directory. On an Edge Transport server, configuration information is stored in and accessed from the Active Directory Lightweight Directory Services (AD LDS) instance on the local server. Microsoft Windows and Exchange 2010 services work together to create mappings of the configuration data. These mappings are cached in routing tables. Exchange 2010 references these tables when it makes routing decisions. The cache is updated when the routing topology changes. The Exchange services that are used during message transport are common to both the Hub Transport server role and the Edge Transport server role. However, the Edge Transport server role doesn't cache information about the Active Directory topology.

The following configuration and service components are important to message routing:

• Active Directory sites   An Active Directory site represents the routing boundary for Hub Transport servers. A Hub Transport server delivers directly to Mailbox servers, distribution group expansion servers, and to source servers for connectors in the local Active Directory site and to Edge Transport servers subscribed to that site. However, a Hub Transport server must relay messages to another Hub Transport server for recipients, expansion servers, and connectors that are located in remote Active Directory sites. The Hub Transport server role must be deployed in every Active Directory site that contains other Exchange 2010 server roles.

• Active Directory IP site links   Active Directory IP site links define logical paths between Active Directory sites. Exchange 2010 references the IP site link objects to determine the least-cost routing path of remote Active Directory sites.

• Send connectors   Send connectors are used for sending messages to other SMTP hosts. The address space configuration on Send connectors are used to make routing decisions. When a message is delivered to an external domain, the routing destination is typically a Send connector. An Exchange organization that accepts messages for more than one e-mail domain may decide to create Send connectors that are dedicated to each address space. For more information about Send connector selection for routing messages to external domains, see External Message Routing.

• Delivery agents   Delivery agents are used to route messages to foreign systems that don't use SMTP protocol for message transfer. The address space and protocol configuration of delivery agents are used when making routing decisions.

• Foreign connectors   Foreign connectors use drop directories to send messages to foreign systems that don't use SMTP protocol for message transfer. Exchange uses the configuration of Foreign connectors when making routing decisions.

• Routing groups   Routing groups represent a routing boundary for Exchange Server 2003. If Exchange 2010 is deployed in an existing Exchange 2003 organization, routing must consider the location of servers within routing groups to deliver a message to a mailbox or a connector that resides on Exchange 2003. To implement compatibility with Exchange 2003, all computers running Exchange 2010 deployed in the organization belong to a single, global routing group.

• Routing group connectors   Routing group connectors define logical paths between Exchange routing groups. If Exchange 2010 is deployed in an existing Exchange 2003 organization, messages are routed between server versions through routing group connectors. When the first Hub Transport server is deployed, the setup process prompts you to create a routing group connector from the global Exchange 2010 routing group to a legacy routing group. For more information about message routing in an environment where more than one version of Exchange is deployed, see Internal Message Routing.

• Microsoft Exchange Transport service   The Microsoft Exchange Transport service is the SMTP provider for Exchange 2010 and controls every component of message processing, from SMTP IN to SMTP OUT. A series of configurable SMTP Receive agents are triggered at various SMTP events. The Microsoft Exchange Transport service enables these agents to process messages as they pass through SMTP transport and perform anti-spam, antivirus, and other tasks before messages are submitted to the categorizer. The Microsoft Exchange Transport service also uses the topology discovery module for Exchange topology discovery.

• Microsoft Exchange Active Directory Topology service   The Microsoft Exchange Active Directory Topology service is responsible for locating the domain controllers and global catalog servers that Exchange 2010 can use to retrieve configuration and recipient data from Active Directory. The Microsoft Exchange Active Directory Topology service is also responsible for keeping Active Directory site affinity for an Exchange 2010 server up to date.

• Routing tables   The routing tables hold the information that the routing component uses to make routing decisions. The routing table is composed of a map of topology components and their relationship to one another.

• DNS Exchange 2010 uses an enhanced Domain Name System (DNS) client, a component of the Microsoft Exchange Transport service, to resolve the next hop selection to a list of target server names. The standard DNS client is used to resolve that list of server names to IP addresses. Enhanced DNS also provides load-balancing functionality for Exchange 2010 transport servers by using round robin.

• SMTP SMTP is used for communication when messages are relayed between SMTP servers. An SMTP server can be a Hub Transport server, Edge Transport server, Exchange 2003 server, or a smart host. A Hub Transport server uses remote procedure call (RPC) to deliver messages directly to Mailbox servers that have the same Active Directory site membership as the Hub Transport server.

Return to top

Using Active Directory Sites for Routing

An Active Directory site is a logical configuration component that's based on the physical aspects of the network. The primary purpose for creating an Active Directory site is to define which subnets in the network are connected in a way that optimizes control of Active Directory replication traffic. The Active Directory site represents a routing boundary for Exchange 2010. Computers that have the Hub Transport server role installed make routing decisions based on the Active Directory site topology.

Determining Site Membership

By default, an Active Directory forest contains only one Active Directory site. The default name for this Active Directory site is Default-First-Site-Name. If no other Active Directory sites are created, all domain member computers in the forest are members of Default-First-Site-Name. You don't have to configure a subnet-to-site association. If additional Active Directory sites are created, you must specify the subnets that are assigned to that Active Directory site.

Each Active Directory site is associated with one or more IP subnets. An administrator assigns Active Directory site membership to computers that are configured as domain controllers and global catalog servers. Other domain member computers, such as Exchange servers, are assigned Active Directory site membership automatically when they're configured to use an IP address that's in an IP subnet that's associated with an Active Directory site. Computers that have the same Active Directory site membership are presumed to have good network connectivity. A server is always a member of a single Active Directory site.

When an application can determine the Active Directory site membership of the computer where it's installed and of other computers in the forest, and then use that information to control communication flow, it's a site-aware application. When site-aware applications must use the services of another server, such as a domain controller or global catalog server, priority is given to the servers that have the same Active Directory site membership as the computer that's requesting those services.

Exchange 2010 is a site-aware application and uses the Active Directory topology for message routing and to communicate with the services that are running on computers that have other Exchange 2010 server roles installed. The Active Directory site isn't only the routing boundary. It's also the service discovery boundary.

Determining site membership for a domain member computer depends on a series of DNS queries to compare the local IP address to defined subnets and then determine the appropriate site membership association. To reduce the overhead that's associated with DNS queries, the Exchange 2010 Active Directory schema additions include the msExchServerSite attribute for the Exchange server object. The value of this attribute is the distinguished name of the Active Directory site of an Exchange server. This attribute is a property of each Exchange server object. When site membership affinity is stored as an attribute of the server object, the current topology can be read directly from Active Directory instead of relying on DNS queries and a site membership association is enabled for a non-domain computer, such as a subscribed Edge Transport server.

The value for the msExchServerSite attribute is populated and kept up to date by the Microsoft Exchange Active Directory Topology service. When a Windows-based computer starts, the Net Logon service determines site membership for the computer. The Net Logon service uses that information to locate domain controllers that are located in the same Active Directory site as the local computer and then directs authorization and authentication requests to those servers. The Microsoft Exchange Active Directory Topology service uses the DsGetSiteName API call to retrieve the site membership value from the Net Logon service and writes the Active Directory site's distinguished name to the msExchServerSite attribute for the Exchange server object in Active Directory.

The following table shows how an organization might define Active Directory sites. In this example, three Active Directory sites are defined, and each Active Directory site is associated with more than one IP subnet.

Example of an Active Directory site-to-subnet association

Active Directory site name	Associated IP subnets
Site A	192.168.1.0/24 192.168.2.0/24
Site B	192.168.3.0/24 192.168.4.0/24
Site C	192.168.5.0/24 192.168.6.0/24

If a server named HubTransportA has the IP address of 192.168.1.1, it's a member of Site A. By changing the IP address of a server, you may change its site membership. If you change the IP address of HubTransportA to 192.168.2.1, it won't change the server's Active Directory site membership because that subnet is also associated with Site A. However, if you move the server and the IP address changes to 192.168.3.1, the server would be considered a member of Site B.

A change in site membership can also occur if you change the association of subnets to Active Directory sites. For example, if you remove the subnet 192.168.3.0 from association with Site B and associate it with Site A, the site membership of a server that has the IP address of 192.168.3.1 also changes to Site A. Whenever a change in site membership occurs, Exchange 2010 must update its configuration data so that the change is considered when Exchange 2010 makes routing decisions. Some latency occurs between the time that a change in an Active Directory site membership occurs and the topology change is fully propagated. The following communication must occur in the following order to propagate topology changes:

1. The change in site membership is written to a domain controller. The updated information replicates between the domain controllers in each Active Directory site in the forest. The time that's required for the change to propagate fully throughout the forest depends on the Active Directory replication topology and schedule as defined by site links.

2. The Net Logon service runs on all Windows-based computers and polls frequently for changes in Active Directory site membership. The Net Logon service polls at five-minute intervals. Therefore, the change is detected by the Net Logon service within five minutes of the local domain controller receiving the update.

3. The Microsoft Exchange Active Directory Topology service queries the Net Logon service at 15-minute intervals to determine the Active Directory site membership of the local Exchange server. If a change is detected, the Microsoft Exchange Active Directory Topology service updates the MsExchServerSite attribute.

4. The changed site attribute value of the Exchange server configuration object is then replicated throughout the organization. The Exchange servers in the organization detect this change. Then the routing tables are updated with the new Active Directory site membership attribute value.

Some latency occurs between the time that an Active Directory site membership change takes effect and the time that the updated information is available to another Exchange 2010 server. For more information about how Exchange 2010 handles these types of configuration changes, see "Rerouting and the Unreachable Queue" later in this topic.

IP Site Links

Site links are logical paths between Active Directory sites. A site link object represents a set of sites that can communicate at a uniform cost through a specified intersite transport. Site links don't correspond to the actual path taken by network packets on the physical network. However, the cost assigned to the site link by the administrator typically relates to the underlying network reliability, speed, and available bandwidth. For example, the Active Directory administrator would assign a lower cost to a network connection with a speed of 100 megabits per second (Mbps) than to a network connection with a speed of 10 Mbps.

By default, all site links are transitive. This means that if Site A has a link to Site B, and Site B has a link to Site C, Site A is transitively linked to Site C. The transitive link between Site A and Site C is also known as a site-link bridge.

An Active Directory site link can be configured to use either IP or SMTP as the transport protocol for communication. An SMTP site link is limited in the types of data that can be replicated by using that protocol and is designed to provide a store and forward mechanism for replication between Active Directory sites that don't have a reliable network link. An IP site link isn't limited in the types of data that can be replicated across it. Exchange 2010 uses only IP site links to determine its routing topology. The cost that's assigned to the IP site link will be considered by the routing component of Exchange 2010 when calculating a routing table. These costs are used to calculate the least-cost routing path to the ultimate destination for a message.

Every Active Directory site must be associated with at least one IP site link. There is a single default IP site link named DEFAULTIPSITELINK. When you create an Active Directory site, you must associate that site to an IP site link. You can create additional IP site links to implement the desired topology, or you can associate every Active Directory site to the DEFAULTIPSITELINK. Each Active Directory site that's part of an IP site link can communicate directly with every other site in that link at a uniform cost.

In the following figure, four Active Directory sites are configured in the forest. Every site has been associated with the DEFAULTIPSITELINK. Therefore, each Active Directory site communicates directly with every other site by using the same cost metric. More than one communication path is indicated, but only a single IP site link is defined.

Full mesh topology with a single IP site link

In the following figure, four Active Directory sites are configured in the forest. In this topology, the administrator has configured IP site links to create a hub-and-spoke topology of Active Directory sites. Each spoke site can communicate directly with the central site, and the spoke sites can communicate with one another by using the transitive IP site links.

Hub-and-spoke topology of Active Directory IP site links

It's important to note that Exchange uses site links only when determining the least-cost path, but will always try to deliver messages directly to the destination Hub Transport server. For example, if a user in Site B in the topology shown in the preceding figure sends a message to another user in Site C, the Hub Transport server in Site B will connect directly to the Hub Transport server in Site C. If you want to force messages to go through Site A, you must enable that site as a hub site. For more information about hub sites, see "Implementing Hub Sites" later in this topic.

An Active Directory administrator implements the topology that best represents the connectivity and communication requirements of the forest. Because the same topology is used by Exchange 2010, you must make sure that the current topology supports efficient messaging communication.

The default cost for a site link is 100. A valid site link cost can be any number from 1 through 99,999. If you specify redundant links, the link with the lowest cost assignment is always preferred. An Exchange organization administrator can assign an Exchange-specific cost to an IP site link. If an Exchange cost is assigned to an IP site link, it will be used by Exchange 2010. Otherwise, the Active Directory cost is used. For more information about how to set an Exchange cost on an IP site link, see "Controlling IP Site Link Costs" later in this topic. An administrator who has membership in the Enterprise Administrators group can create additional IP site links.

For more information about Active Directory site configuration, see Designing the Site Topology.

Controlling IP Site Link Costs

Active Directory IP site links costs are based on relative network speed compared to all network connections in the WAN and are designed to produce a reliable and efficient replication topology. Therefore, in most cases, the existing IP site link costs should work well for Exchange 2010 message routing. However, if after documenting the existing Active Directory site and IP site link topology, you verify that the Active Directory IP site link costs and traffic flow patterns aren't optimal for Exchange 2010, you can make adjustments to the costs evaluated by Exchange. Changing the cost assigned to the IP site link by using Active Directory tools would impact the entire environment. Instead, use the Set-AdSiteLink cmdlet in the Exchange Management Shell to assign an Exchange-specific cost to the IP site link. For example, to set a different cost on the IP site link SITELINKAB for message routing purposes, run the following command in the Shell.

Set-AdSiteLink -Identity SITELINKAB -ExchangeCost 25

When an Exchange cost is assigned to an IP site link, the Exchange cost overrides the Active Directory cost for message routing purposes, and routing only considers the Exchange cost when it evaluates the least-cost routing path.

Adjusting IP site link costs can be useful when the message routing topology has to diverge from the Active Directory replication topology. Exchange costs can be used to force all message routes to use a hub site. Exchange costs can also be used to control where messages are queued when communication to an Active Directory site fails. The following figure shows an Active Directory topology with four sites.

Topology with Exchange costs configured on IP site links

In the preceding figure, the network connection between Site C and Site D is a low bandwidth connection that's only used for Active Directory replication and shouldn't be used for message routing. However, the Active Directory IP site link costs cause that link to be included in the least-cost routing path from any other Active Directory site to Site D. Therefore, messages are delivered to the Site D queue in Site C. The Exchange administrator prefers that the least-cost routing path include Site B instead so that if Site D is unavailable, the messages will queue at Site B. Configuring a high Exchange cost on the IP site link between Site C and Site D prevents that IP site link from being included in the least-cost routing path to Site D.

Exchange 2010 provides support for configuration of a maximum message size limit on an Active Directory IP site link. By default, Exchange 2010 doesn't impose a maximum message size limit on messages that are relayed between Hub Transport servers in different Active Directory sites. If you use the Set-AdSiteLink cmdlet to configure a maximum message size on an Active Directory IP site link, routing generates a non-delivery report (NDR) for any message that has a size larger than the maximum message size limit that's configured on any Active Directory site link in the least-cost routing path. This configuration is useful for restricting the size of messages that are sent to remote Active Directory sites that must communicate over low-bandwidth connections. For more information, see Understanding Message Size Limits.

Implementing Hub Sites

In your Exchange organization, you may have to force all message delivery to be relayed through a particular Active Directory site. In this scenario, connectivity may prevent direct SMTP relay between sites. Therefore, messages must be relayed through an interim site before they're sent to their destination. Because of an Exchange organization's internal policies, an administrator may also want to relay all messages through a particular site. You can use Shell cmdlets to designate an Active Directory site as a hub site. By designating an Active Directory site as a hub site, you cause additional overall overhead because more servers are involved in message delivery. For example, consider a message that's sent from Site A to Site E. If the least-cost routing path is Site A-Site B-Site C-Site D-Site E, and you designate Site C as a hub site, the message is relayed from Site A to Site C and then relayed from Site C to Site E.

You use the Set-AdSite cmdlet to specify an Active Directory site as a hub site. Whenever a hub site exists along the least-cost routing path for message delivery, the messages queue and are processed by the Hub Transport servers in the hub site before they're relayed to their ultimate destination.

After the least-cost routing path is chosen, routing determines whether there's a hub site along that routing path. If a hub site is configured, messages stop at a Hub Transport server in the hub site before they're relayed to the target destination. If there's more than one hub site along the least-cost routing path, messages stop at each hub site along the routing path.

This variation to direct relay routing only is in effect when the hub site is located along the least-cost routing path. The following figure shows the correct use of a hub site. In this diagram, Site B is configured as a hub site. Messages that are relayed from Site A to Site D are relayed to Site B before they're delivered to Site D.

Message delivery with a hub site

The following figure shows how IP site link costs affect routing to a hub site. In this scenario, Site B has been designated as a hub site. However, because it doesn't exist along the least-cost routing path between any other sites, queuing at Site B before delivery to the destination doesn't occur. An Active Directory site is never used as a hub site if it isn't on the least-cost routing path between two other sites.

Misconfigured hub site

You can configure any Active Directory site as a hub site. However, for this configuration to work correctly, you must have deployed at least one Hub Transport server in the hub site.

Topology Discovery

The Exchange 2010 topology relies on the Active Directory site topology and doesn't have its own configuration. The Active Directory topology is made available to Exchange 2010 by the following required elements:

• The Microsoft Exchange Active Directory Topology service

• The topology discovery module inside the Microsoft Exchange Transport service

The Microsoft Exchange Active Directory Topology service runs on all Exchange 2010 server roles, except the Edge Transport server role. These Exchange 2010 servers use the Microsoft Exchange Active Directory Topology service to discover the domain controllers and global catalog servers that can be used by the Exchange servers to read and write Active Directory data. Exchange 2010 binds to the identified directory servers whenever Exchange has to read from or write to Active Directory.

The topology discovery module is part of the Microsoft Exchange Transport service and provides information about the Active Directory topology to Exchange servers. This API discovers the Exchange servers and roles in the organization and determines their relationship to the Active Directory configuration objects. Configuration data is retrieved from Active Directory and then cached so that it can be accessed by the Exchange services that are running on that computer.

The topology discovery module performs the following steps to generate an Exchange routing topology:

1. Data is read from Active Directory. All the following objects are retrieved:

   • Active Directory sites.

   • IP site links.

   • All Exchange servers. This includes information about the Exchange 2010 server roles deployed on those servers.

2. The data that's retrieved in step 1 is used to create the initial topology and to begin linking and mapping the related configuration objects.

3. Exchange servers are matched to Active Directory sites by retrieving the site attribute value from the Exchange server object that's stored in Active Directory.

4. Routing tables are updated with the collection of information retrieved.

This process makes every Exchange 2010 server aware of the other Exchange servers in the organization and of how close the Exchange servers are to one another.

Return to top

Exchange 2010 Routing Tables

When the Microsoft Exchange Transport service starts, it calculates a set of routing tables that's based on the snapshot of information that's retrieved from Active Directory or, on an Edge Transport server, from AD LDS. The configuration information that's stored in AD LDS includes available connectors and accepted domains, but doesn't include topology data.

The routing component refers to the routing tables to determine how to route messages to recipients. When configuration changes are made, the routing tables are rebuilt. The new routing tables are used to route new incoming messages. Messages in remote delivery queues are also rerouted if the routing component determines that they're affected by the configuration changes. For more information about message rerouting, see "Rerouting and the Unreachable Queue" later in this topic.

The following configuration data is retrieved from Active Directory and made available to the routing component of Hub Transport servers:

• Active Directory sites

• Active Directory IP site links

• Exchange servers and their relationship to Active Directory sites

• SMTP connectors

• Non-SMTP connectors

  Note

  Non-SMTP connectors include Exchange 2010 delivery agent connectors, Foreign connectors, and in coexistence scenarios, any non-SMTP connectors hosted by Exchange 2003.

• Routing groups

• Routing group connectors

• Mailbox stores (private message databases (MDBs))

• Public folder stores (public MDBs)

• Public folder hierarchies

Based on this data, the routing component of the Microsoft Exchange Transport service populates routing tables to help streamline routing decisions. The routing table correlates the data to create a topology map. This topology map contains the following elements:

• Linked connectors map   This map correlates the identifiers of Receive connectors on the local server to the linked Send connector.

• Server map   All Exchange 2010 and Exchange 2007 Hub Transport servers, Edge Transport servers, Mailbox servers, and Exchange 2003 servers in the organization are contained in the server map. This map correlates the distinguished name of each Exchange server to server routing data. This includes the total cost to reach that server.

• Legacy server map   All Exchange Server 2007 Hub Transport servers, Edge Transport servers, Mailbox servers, and Exchange 2003 servers in the organization are contained in the legacy server map. This map correlates the legacy distinguished name of each Exchange server to server routing data. This includes the total cost to reach that server. This map supports store override functionality. Store override functionality is specific to public folders. For more information, see "Routing to Public Folders" in Internal Message Routing.

• MDB map   All MDBs in the organization are contained in the MDB map. This map correlates the distinguished name of each MDB to server routing data. This includes the total cost to reach that server.

• Active Directory site map   This map correlates each Active Directory site to a structure that contains the least-cost routing path from the local site to every other site. The map includes any hub sites along the least-cost routing path. Each routing path hop also identifies all Hub Transport servers in that site that will be used by the enhanced DNS component.

• Routing groups map   This map associates the total cost and first hop routing group connector for the least-cost routing path from the Exchange 2010 routing group to each legacy routing group.

• Send connectors map   This map identifies the Send connectors configured in the organization and the source servers for each connector.

The routing tables are built every time that a transport server is started and recalculated when configuration changes are received. Configuration changes can be detected in any of the following ways:

• Active Directory change notifications   There is a delay between the time that a notification is received and the time that the change is written to the routing tables. This delay lets the routing component batch the changes and process more than one change in a single operation. By default, each notification causes the routing component to delay processing by five seconds. For example, if five notifications are received exactly one second after the previous notification, routing delays processing the change for a total of nine seconds.

• Configuration reloading caused by service control commands The routing component reloads the configuration data when the Microsoft Exchange Transport service is restarted.

• Periodic reload to track changes that aren't supported by Active Directory notifications   By default, routing will periodically reload the configuration data to make sure that all changes are tracked. The configuration reload occurs at six-hour intervals.

The information in the routing tables is logged to routing logs. By default, these logs are located in the C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\Routing folder. A new log is generated every time that the routing tables are calculated. If for some reason the Hub Transport server is unable to contact Active Directory, routing continues to make routing decisions based on the currently cached data, even though that data may not be up to date. For more information, see Understanding Routing Table Logging.

Return to top

Receiving Messages for Routing

A message can arrive at a Hub Transport server in any of the following ways:

• E-mail is received from an Internet-facing SMTP server for delivery to a recipient in the Exchange organization or to a recipient in an internal relay accepted domain.

• E-mail is received from another Hub Transport server in the Exchange organization for delivery to a recipient mailbox that's located on a Mailbox server in that Active Directory site.

• E-mail is received from SMTP clients. These are typically POP3 or IMAP4 users that may exist in your environment.

• E-mail is received from Pickup and Replay directories on a Hub Transport server. These directories are typically used by Foreign connectors to transmit messages to your Exchange infrastructure.

• E-mail is retrieved from an Exchange 2010 Mailbox server by the Hub Transport server.

• E-mail is received from an Exchange 2007 or Exchange 2003 server for delivery to a recipient mailbox that's located on an Exchange 2010 Mailbox server.

Processing of all e-mail that's received by a Hub Transport server for categorization begins in the Submission queue.

Receiving Messages from Edge Transport Servers, Other Exchange Hub Transport Servers, and SMTP Clients

In this scenario, messages are received from Edge Transport servers, Hub Transport servers, or other third-party SMTP hosts by using standard SMTP connections. The remote host initiates an SMTP connection and transfers the messages to the Hub Transport server. Hub Transport servers use Receive connectors for accepting incoming SMTP connections. Each Hub Transport server has two Receive connectors created during setup. One of these connectors is used to receive authenticated SMTP connections from other Exchange servers. The second one is used to receive SMTP connections from SMTP clients used by POP3 or IMAP4 users in your organization. These two Receive connectors have different permissions configured that are appropriate for their intended use. To learn more about Receive connectors, see Understanding Receive Connectors.

By default, Hub Transport servers don't accept unauthenticated anonymous connections. If you need to enable this functionality, we recommend that you create a separate Receive connector to handle the anonymous connections. For more information, see Allow Anonymous Relay on a Receive Connector.

Collecting Messages from Pickup and Replay Directories

Messaging systems that don't use SMTP as the transfer protocol can be connected to your Exchange organization using Foreign connectors. When a message is sent to an Exchange user from a remote system, the Foreign connector writes that message to a special directory on the Hub Transport server called the Pickup directory. The Hub Transport server periodically checks the Pickup directory for new messages. When it detects a new message, the Hub Transport server then converts the message to an Exchange e-mail message and routes it as a regular message. To learn more about how the Pickup and Replay directories are used, see Understanding the Pickup and Replay Directories.

Retrieving Messages from a Mailbox Server

In this scenario, the Microsoft Exchange Mail Submission service that runs on Mailbox servers notifies a Hub Transport server that's located in the same Active Directory site that messages are ready for retrieval from a sender's outbox. Each Mailbox server maintains a list of Hub Transport servers that are located in the same Active Directory site. This list of Hub Transport servers is known as the submission server list. The server discovery process repeats every ten minutes to keep the list up to date.

If more than one Hub Transport server is located in the same Active Directory site as the Mailbox server that's submitting a notification that mail is ready for retrieval, the following process is used to select the server:

• If the local Mailbox server is also running the Hub Transport server role and it is not participating in a database availability group (DAG), the local server is notified. If the local Microsoft Exchange Transport service isn't running or the local Hub Transport server can't process new mail submissions because of back pressure, another available Hub Transport server is notified. For more information about back pressure, see Understanding Back Pressure.

• If the local Mailbox server is also running the Hub Transport server role and is also participating in a DAG, it first tries to notify any Hub Transport server in the site before notifying the local Hub Transport server. This is done to avoid having redundant copies of messages on the same server hardware. To learn more about coexisting Mailbox and Hub Transport server roles when using DAGs, see Hub Transport and Mailbox Server Roles Coexistence When Using DAGs.

• If the local Mailbox server isn't running the Hub Transport server role, notifications are load balanced among Hub Transport servers by using round robin.

• If the selected Hub Transport server can't be contacted, the Microsoft Exchange Mail Submission service fails over to a different Hub Transport server in the same Active Directory site. The failing server is marked as inactive, and the next Hub Transport server in the submission server list is selected. If no Hub Transport servers in the local Active Directory site are available, the submission server list is empty. In this case, an event is logged and mail submission notifications are temporarily stopped. Hub Transport servers that are marked as inactive are retried after five minutes.

By default, the Microsoft Exchange Mail Submission service load balances notification events across the Hub Transport servers in a site so that each Hub Transport server receives an equal distribution of notification events to process. In some circumstances, providing an equal distribution may not be an optimal solution. Not all Hub Transport servers have the same capacity, and some messages require additional processing. For example, a message that has a large attachment or many recipients takes longer for a Hub Transport server to process than a small message that's addressed to only one recipient. If you want to create a static list of Hub Transport servers that a Mailbox server should notify, you can use the Set-MailboxServer cmdlet in the Shell. Use the SubmissionServerOverrideList parameter to specify a list of Hub Transport servers that the local Mailbox server will notify when it has mail for retrieval. For more information about how to configure this setting, see Set-MailboxServer.

After a Hub Transport server receives a mail submission notification from a Mailbox server, it uses the store driver to retrieve the message from the mailbox database and put it in the Submission queue on the Hub Transport server. The transfer of the message from the Mailbox server to the Hub Transport server happens by using Exchange RPC.

Receiving Messages from Legacy Exchange Servers

Due to the changes made to the Exchange Server Object (XSO) model in Exchange 2010, Exchange 2010 Hub Transport servers can't pick up messages from and deliver messages to Exchange 2007 Mailbox servers. Similarly Exchange 2007 Hub Transport servers can't communicate with Exchange 2010 Mailbox servers. All messages sent from Exchange 2007 recipients are first picked up from the Mailbox servers by Exchange 2007 Hub Transport servers and are then relayed to Exchange 2010 Hub Transport servers. To learn more about message routing when coexisting with Exchange 2007, see Upgrade from Exchange 2007 Transport.

As opposed to Active Directory sites, Exchange 2003 uses routing groups to route messages. Routing groups are connected to each other using routing group connectors. To support coexistence between these two routing topologies, all Exchange 2010 servers are automatically added to a single routing group when Exchange 2010 is installed in an Exchange 2003 organization. All messages that originate on Exchange 2003 mailboxes are delivered to the Exchange 2010 environment through the routing group connectors between the Exchange 2010 routing group and the Exchange 2003 routing groups. To learn more about message routing when coexisting with Exchange 2003, see Upgrade from Exchange 2003 Transport.

Return to top

Routing Messages

After a Hub Transport server or an Edge Transport server receives a message, it determines the ultimate destination and uses the Exchange topology and connector configurations to determine the least-cost routing path. After the routing path is determined, the message is delivered to the next hop on the routing path.

Although this topic explains how Exchange makes routing decisions in general, the following two topics provide additional information about specific routing scenarios. The internal message routing topic discusses message delivery to Mailbox servers, public folders, and legacy servers. The external message routing topic discusses routing messages to recipients that are outside your Exchange organization. The topic also discusses the roles of Send connectors, delivery agent connectors, and Foreign connectors.

• Internal Message Routing

• External Message Routing

Determining the Ultimate Destination

The previous section described the various sources from which a Hub Transport server can receive messages. When a message is received by a Hub Transport server, the message must be categorized. The first phase of message categorization is recipient resolution. After the recipient has been resolved, the ultimate destination can be determined. The next phase, routing, determines how to best reach that destination. A single, deterministic route is selected. That route isn't recalculated unless the routing configuration changes.

From the perspective of the sending server, each delivery queue represents the destination for a particular message. When the Hub Transport server or Edge Transport server selects the destination for a message, the destination is stamped on the recipient as the NextHopSolutionKey attribute. If a single message is being sent to more than one recipient, each recipient has the NextHopSolutionKey attribute. The receiving server also performs message categorization and queues the message for delivery. After a message is queued, you can examine the delivery type for a particular queue to determine whether a message will be relayed again when it reaches the next hop destination.

The destination for a message can be classified as one of the following delivery types:

• DNS connector delivery   The messages are queued for delivery to an external recipient by using an SMTP Send connector for which the local server is a source server. The connector is configured to use DNS to resolve the recipient addresses.

• Smart host connector delivery   The messages are queued for delivery to an external recipient by using an SMTP Send connector for which the local server is a source server. The connector is configured to use a smart host for delivery.

• SMTP relay in an Active Directory site to an Edge Transport server   The messages are queued for delivery to an external recipient by using an SMTP Send connector for which the source server is an Edge Transport server that's subscribed to the local Active Directory site.

• SMTP relay in an Active Directory site to a Hub Transport server   The messages are queued for delivery to a Hub Transport server that's located in the same Active Directory site as the local server. The destination server can be an Exchange 2007 Hub Transport server, the source server for a Send connector, a delivery agent connector or Foreign connector, the source server of a routing group connector, or a distribution group expansion server.

• SMTP relay to a remote Active Directory site   The messages are queued for delivery to a Hub Transport server that's located in a remote Active Directory site. The ultimate destination server in the remote Active Directory site can be any of the following:

  • The source server for a connector that's configured to transport messages for external recipients

  • The source server for a routing group connector

  • A distribution group expansion server

  • A Mailbox server that's located in the remote Active Directory site

  The messages are delivered to one of the Hub Transport servers in the destination site. The receiving server relays the message within the Active Directory site if it's necessary.

• SMTP relay to a legacy routing group   The messages are queued for delivery to the first hop routing group connector used to reach an Exchange 2003 routing group. The ultimate destination server can be any of the following:

  • The source server for a connector

  • An expansion server

  • An Exchange 2003 bridgehead server that delivers messages addressed to mailbox recipients that are located in the routing group

• MAPI delivery The messages are queued for delivery to a recipient's mailbox, a public folder, or a public folder store that's located on a Mailbox server that's located in the local Active Directory site.

• Non-SMTP gateway delivery   The messages are queued for delivery to an external recipient by using a delivery agent connector or Foreign connector for which the local server is a source server. This delivery type is used only when the messages are being delivered to delivery agent connectors or the Foreign connector drop directory on the local server.

• Unreachable A route to the recipient couldn't be determined and the messages are located in the Unreachable queue.

Determining the Least-Cost Routing Path

The least-cost routing path to the remote Active Directory site is determined by the calculation of all the costs assigned to the Active Directory IP site links that exist between the two sites. The links are bridged, and a direct connection occurs. Exchange 2010 Hub Transport servers always select a single, deterministic least-cost routing path. Availability of the underlying connection or destination server is never a consideration in routing path selection, and no alternative routing path is considered.

The least-cost routing path calculation is used to determine a backoff path when message delivery to the next hop fails. In Exchange 2010, backoff is a mechanism used to deliver messages at an interim hop along the least-cost routing path when direct relay fails for any reason, such as network issues or servers going offline. The routing component tries to deliver messages as close to the destination as possible by backing off, hop by hop, along the least-cost routing path until a connection is made. First, a connection attempt is made to each Hub Transport server in the destination Active Directory site. If no Hub Transport servers in the Active Directory site respond, the least-cost routing path is checked to determine how to start backing off from the delivery site. The goal is to deliver the message as close as possible to the destination and queue it at a Hub Transport server in that Active Directory site.

Depending on the individual message routing scenario, the following factors may influence the selection of a least-cost routing path:

• Linked connectors   If the Receive connector that the message is received on is linked to a Send connector, messages are routed to that Send connector regardless of cost. This configuration always takes precedence.

• The cost assigned to the IP site links and routing group connectors that must be traversed to reach the destination If more than one routing path exists between a source server and a destination server, the routing path with the lowest aggregate cost is selected.

• The address space assigned to a Send connector   The Send connector with the most specific address space match to the destination is selected.

• The cost assigned to the address space configured on a Send connector If more than one Send connector is assigned the same address space, the routing component compares the cost assigned to the address space. The Send connector with the lowest cost is selected.

• Connector scope   A connector may be limited to use by Exchange 2010 servers that are located in the same Active Directory site as the source transport servers for the connector. In earlier versions of Exchange, the connector scope could be limited to servers that have the same routing group membership.

• Message size restrictions   The message size constraint specified on a connector must be larger than the size of the message being routed. Connectors with a message size restriction that's less than the size of the message are eliminated from routing consideration.

• The proximity of the destination to the sending server   Routing will prefer the server that's closest, in this order: local server, server in the same Active Directory site, or server in a remote Active Directory site or routing group.

• The name assigned to an Active Directory site If more than one routing path results in the same aggregate cost, the routing component makes an alphanumeric comparison of the name of the Active Directory sites that precede the target site along each routing path. The routing path where the Active Directory site nearest to the destination is lowest in alphanumeric order is used.

• The name assigned to a routing group connector   If more than one routing path results in the same aggregate cost, the routing component makes an alphanumeric comparison of the name of the routing group connectors that come before the target destination along each routing path. The routing path where the routing group connector nearest to the destination is lowest in alphanumeric order is used.

• The connector state   The Exchange 2010 routing component only considers enabled connectors when it calculates the routing path. However, earlier versions of Exchange don't consider connector state.

The following logic is used to select the routing path:

1. First, calculate the least-cost routing path by adding the cost of the IP site links and of any routing group connectors that must be traversed to reach the destination. If the destination is a connector, the cost assigned to the address space is added to the cost to reach the selected connector. If multiple routing paths are possible, only the routing path with the lowest aggregate cost is used.

2. If more than one routing path has the same aggregate cost, the number of hops in each path is evaluated and the routing path with the least number of hops is used.

3. If more than one routing path is still available, the name assigned to the Active Directory sites or routing group connectors before the destination are considered. The routing path where the Active Directory site nearest the destination is lowest in alphanumeric order is used. If the site nearest the destination is the same for all routing paths being evaluated, an earlier site name is considered.

The following figure shows the routing topology for an Exchange organization. This topology is used in the following examples to demonstrate the logic used by the routing algorithm to select the least-cost routing path.

Exchange 2010 routing topology

Example 1   A message that's being relayed from Site A to Site D can follow two possible routing paths: Site A-Site B-Site D and Site A-Site C-Site D. The costs assigned to the IP site links in each routing path are added to determine the total cost to route the message. In this example, the routing path Site A-Site B-Site D has an aggregate cost of 20. The routing path Site A-Site C-Site D has an aggregate cost of 10. Routing selects path Site A-Site C-Site D.

Example 2   A message is being relayed from Site B to Site D. There are three possible routing paths: Site B-Site D with a cost of 15, Site B-Site E-Site C-Site D with a cost of 15, and Site B-Site A-Site C-Site D with a cost of 15. Because more than one routing path results in the same cost, routing selects the routing path Site B-Site D. This has the least number of hops.

Example 3   A message is being relayed from Site A to Site E. There are two possible routing paths: Site A-Site B-Site E with a cost of 10, and Site A-Site C-Site E with a cost of 10. Both routing paths have the same cost and same number of hops. The alphanumeric order of the Active Directory sites immediately before Site E is compared. Site B has a lower alphanumeric value than Site C. Therefore, routing selects the routing path Site A-Site B-Site E.

After the least-cost routing path has been determined, the Exchange 2010 routing component doesn't consider alternative routing paths.

Next Hop Selection

Exchange 2010 Hub Transport servers don't relay to each Active Directory site along the least-cost routing path. After the routing path is determined, the message is relayed directly from the source server to the next hop. The next hop selection tries to deliver the messages as close as possible to the ultimate destination. Additional intrasite relay may be required to arrive at the ultimate destination. When routing to legacy routing groups, direct relay to the Active Directory site where the source server for the first hop routing group connector resides occurs. After the message is relayed to the legacy environment, standard legacy routing occurs.

The following figure shows a simple Exchange topology and illustrates many of the Exchange routing components.

Exchange topology and routing components

Using the preceding figure as a reference, a message that's sent from Mailbox1 in Site A, to the external recipient joe@contoso.com is processed as follows:

1. The Microsoft Exchange Mailbox Submission service that's running on Mailbox1 notifies an Exchange 2010 Hub Transport server that's located in the same Active Directory site of the new mail item for transport.

2. Using RPC, the store driver component on an Exchange 2010 Hub Transport server in the same Active Directory site retrieves the message and puts it in the Submission queue on the local server.

3. From the Submission queue, the message moves through categorization. The categorizer first performs recipient resolution and determines that joe@contoso.com is an external recipient.

4. The routing component selects the best connector through which to route the message and calculates the least-cost routing path to that connector. In this example, a Send connector has the address space *.contoso.com and is the connector selected by the routing component. All the source servers for this Send connector are located in Site B.

5. The routing component determines the next hop required to reach a source server for the Send connector. The Hub Transport server in Site A queues the message for SMTP delivery to Site B.

6. If the receiving server in Site B is a source server for the Send connector, it queues the message for delivery to that Send connector. If the receiving server isn't a source server for the *.contoso.com Send connector, the message is relayed by using SMTP to a Hub Transport server in Site B that's the source server for the connector.

The following table provides additional examples of the next hop selection for several recipients based on the topology shown in the preceding figure. It isn't a complete list of all routing possibilities. It simply provides examples that are most common in a topology like the one shown in the preceding figure.

Examples of next hop selection in the preceding figure

Receiving server	Ultimate destination	Next hop	Queue delivery type
Hub1	Mailbox1	Mailbox1	MAPI delivery
Hub1	Mailbox2	Hub3	SMTP relay in an Active Directory site
Hub1	Mailbox3	Site B	SMTP relay to a remote Active Directory site
Hub1	Mailbox4	Routing group connector	SMTP relay to a legacy routing group
Hub1	Recipient@fourthcoffee.com	Edge1	SMTP relay to Edge Transport
Hub3	Mailbox1	Hub1 or Hub2	SMTP relay in an Active Directory site
Hub4	Mailbox1	Site A	SMTP relay to a remote Active Directory site
Hub4	Mailbox4	Site A	SMTP relay to a remote Active Directory site
Hub4	Recipient@contoso.com	Contoso SMTP Host	Smart host delivery
Hub4	Recipient@fourthcoffee.com	Site A	SMTP relay to a remote Active Directory site
Edge1	Recipient@fourthcoffee.com	Fourth Coffee SMTP Host	DNS delivery

After the least-cost routing path has been calculated and the next hop destination has been chosen, Exchange 2010 routing tries to relay the message directly to the destination, unless a hub site is configured along the least-cost routing path.

Queue at Point of Failure

The least-cost routing path calculation is used to determine a backoff path when message delivery to the next hop fails. Exchange 2010 tries to deliver messages as close to the destination as possible by backing off, hop by hop, along the least-cost routing path until a connection is made. This behavior is known as queue at point of failure. When the messages are queued at the point in the delivery path where communication failed, it not only speeds up delivery after the problem is resolved, but it will also help you determine why the message delivery failed.

In the topology shown in the following figure, if a message is being delivered from Site A to Site D, the least-cost routing path may be Site A-Site B-Site C-Site D. Delivery will first be tried directly from Site A to Site D. If no Hub Transport server in Site D responds, delivery will be tried to the Hub Transport servers in Site C. This process continues until a Hub Transport server accepts the message. If all intermediate sites are unavailable, the message will be queued at the source site. If the message is queued in Site C, you can start investigating the failure at the Hub Transport servers in Site D or the network connectivity between Site C and Site D.

Queue at point of failure

When the message is queued at the point of failure, the queue is put in a retry state and delivery attempts continue based on the message retry intervals until delivery succeeds or the message expires. The queue is automatically resubmitted for categorization again after a default interval of 12 hours. Queues that have a connector as the next hop destination aren't automatically resubmitted unless a configuration change that causes resubmission occurs. For more information, see Message Rerouting and the Unreachable Queue.

You can use the Mail Flow Troubleshooter to help diagnose problems with mail flow. This tool is a component of the Microsoft Exchange Troubleshooting Assistant and can be run from the Toolbox of the Exchange Management Console.

In more complex topologies, the least-cost routing path between two Active Directory sites can contain many intermediate Active Directory sites. If a network issue occurs somewhere early along the routing path, it may be too inefficient to back off site by site from the end and try to deliver to every one of the intermediate sites. If the routing path is longer than four hops, binary backoff is implemented until four or fewer sites are remaining. Binary backoff means that the next connection attempt is made at the halfway point in the routing path. For example, if the least-cost routing path from Active Directory Site A to Site G is A - B - C - D - E - F - G and the network failure occurs at the link between Site B and Site C, the first connection attempt is made to all Hub Transport servers in Site G. When the connection attempt fails, the next attempt is made to all Hub Transport servers in Site D. This is halfway to Site G. When that connection attempt fails, connection attempts are made to Site C, and Site B because they're closer than four links to the source site. The message will eventually be queued on a Hub Transport server in Site B until the B-C link connectivity is restored.

Delayed Fan-Out

A single e-mail message can be addressed to more than one recipient. These recipients may have internal mailboxes, or they may be external recipients. To route a single message to more than one recipient, the following steps occur:

1. Recipient resolution   Each recipient of the message is resolved to a delivery destination.

2. Routing   The least-cost routing path for each recipient is determined. This includes whether a hub site is configured.

3. Message splitting   To route the message to recipients that have different delivery locations, the message must be split into multiple copies.

After each recipient has been resolved and a routing path to each delivery destination is determined, Exchange 2010 compares the routing path for each recipient. To preserve bandwidth, the bifurcation, or splitting of the message into multiple copies, doesn't occur until a fork in the routing path is encountered.

For example, if multiple recipients of a single message share part or all of the least-cost routing path, a single copy of the message is sent until the message reaches the point in the routing path where a fork occurs. When the divergence in routing paths occurs, the message splits to create a separate copy for each recipient.

In the following figure, a single message is sent from Site A to recipients in Site C, Site D, and Site E. The least-cost routing path is shared until the message reaches Site B. In this scenario, a single copy of the message that contains all recipients is relayed to Site B. This represents the first fork in the routing path. From Site B, a single message copy is routed to the recipient in Site D, and a single copy is relayed to Site C. In Site C, the message splits again. A copy of the message is delivered to the recipient in Site C. And, a copy of the message is relayed to Site E for delivery to the recipient in that site.

Delayed message fan-out

Return to top

Rerouting and the Unreachable Queue

If routing is unable to determine a route for a valid recipient for any reason, the messages are put in the Unreachable queue. Messages in this queue are rerouted when configuration changes are processed and routing tables are recalculated. Messages aren't rerouted in the following scenarios. Instead, an NDR is returned to the sender. The following scenarios result in a message being routed to the Unreachable queue:

• The recipient is a non-SMTP address and a matching connector for the address space can't be found.

• The message doesn't meet the message size restrictions of any matching connector.

Not all configuration changes require resubmission of the messages in the queue. For example, a change to the list of smart hosts for a connector doesn't cause messages to be rerouted. For more information about how messages are rerouted, see Message Rerouting and the Unreachable Queue.

Return to top

 © 2010 Microsoft Corporation. All rights reserved.