Understanding Active Directory Site-Based Routing
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
Microsoft Exchange Server 2007 Hub Transport servers are responsible for routing messages to mailboxes in the organization. In addition, Hub Transport servers are responsible for routing messages that are to be delivered to a remote domain to a connector that is configured to handle message delivery for that remote domain. In Exchange 2007, the intra-organizational message routing topology and routing decisions are based on the existing Active Directory directory service site topology. This topic explains how Exchange 2007 implements Active Directory site-based routing between transport servers in the same Exchange organization.
Overview of Message Routing in Exchange 2007
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 2007 transport server, and after the preliminary processing that occurs during SMTP Receive finishes, the message is delivered to the Submission queue. Messages move from the Submission queue through the categorizer in the following phases:
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 Forefront Security for Exchange Server antivirus agent and the Journaling agent.
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.
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.
Content conversion Before a message is relayed to its next hop, content conversion occurs so that the message is sent in a format that is 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 is specific to an e-mail client, such as HTML to RTF to plain text.
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 is 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, do not bypass the Journaling agent.
Message packaging and DSN generation The final categorized message is assembled and is 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, or the foreign gateway connection handler. This depends on the ultimate destination. 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. If a route cannot be found for a recipient, the messages are queued to the Unreachable queue. Each delivery queue represents the next hop destination.
Figure 1 shows how message processing occurs in the different routing phases and how messages are queued for delivery to the next hop destination.
Figure 1 Routing context in mail flow
.gif "Routing context in mail flow")
Note
This topic focuses on the routing phase of categorization and the topology components and logic that are used to relay messages between Active Directory sites. For more information about message routing to specific recipient types, see the following topics:
• Routing to External Domains
• Internal Message Routing
• Message Routing in a Coexistence Environment
• Routing Messages to Public Folders
The routing topology and components of Exchange 2007 differ significantly from those of Exchange Server 2003 and Exchange 2000 Server but generally correlate in the following ways:
The Active Directory site correlates to routing groups in Exchange 2003 and Exchange 2000.
IP site links correlate to the concept of routing group connectors.
The functionality of the Hub Transport server role in Exchange 2007 correlates to the functionality of a dedicated bridgehead server in Exchange 2003 and Exchange 2000.
However, each Exchange server version differs in the method that is used to determine routing paths. For more information about how these differences affect routing when more than one version of Exchange Server is deployed in the same organization, see Message Routing in a Coexistence Environment.
Intra-organizational Routing Components
To implement Active Directory site-based routing, Exchange 2007 must access configuration information that is stored in Active Directory. On an Edge Transport server, configuration information is stored in and accessed from the Active Directory Application Mode (ADAM) directory service instance on the local server. Microsoft Windows and Exchange 2007 services work together to create mappings of the configuration data. These mappings are cached in routing tables. Exchange 2007 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 does not cache information about the Active Directory topology.
The following configuration and service components are important to internal 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 2007 server roles.
Active Directory IP site links Active Directory IP site links define logical paths between Active Directory sites. Exchange 2007 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 routing messages to address spaces. 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, see Routing to External Domains.
Routing groups Routing groups represent a routing boundary for Exchange 2003 and Exchange 2000. If Exchange 2007 is deployed in an existing organization, routing must consider the location of servers within routing groups to deliver a message to a mailbox or a connector that resides on an earlier version of Exchange Server. To implement compatibility with earlier versions of Exchange Server, all computers that are running Exchange 2007 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 2007 is deployed in an existing Exchange 2003 or Exchange 2000 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 2007 routing group to a legacy routing group. For more information about message routing in an environment where more than one version of Exchange Server version is deployed, see Message Routing in a Coexistence Environment.
Microsoft Exchange Transport service The Microsoft Exchange Transport service is the Simple Mail Transfer Protocol (SMTP) provider for Exchange 2007 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.
Recipient resolution, routing, and content conversion occur during categorization. Additional agents are also triggered at this point of the transport pipeline. The Microsoft Exchange Transport service also uses the topology discovery module for Exchange topology discovery. For more information about the components and processing provided by the Microsoft Exchange Transport service, see Microsoft Exchange Server 2007 Transport Architecture Diagrams.
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 2007 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 2007 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 2007 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 2007 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 2000 server, Exchange 2003 server, or even 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.
Active Directory Sites
An Active Directory site is a logical configuration component that is 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. Replication traffic in an Active Directory site can flow without using connectors or scheduling. However, when replication traffic must flow between Active Directory sites, it is controlled by the configuration of Active Directory site links. Active Directory sites can host servers from more than one domain. And a domain can be represented in more than one Active Directory site.
The Active Directory site represents a routing boundary for Exchange 2007. 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. And 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 are configured to use an IP address that is in an IP subnet that is 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 is installed and of other computers in the forest, and then use that information to control communication flow, it is 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 is requesting those services.
Exchange 2007 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 2007 server roles installed. The Active Directory site is not only the routing boundary. It is 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 is associated with DNS queries, the Exchange 2007 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 msExchangeServerSite attribute for the Exchange server object in Active Directory.
Table 1 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.
Table 1 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 is 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 2007 must update its configuration data so that the change is considered when Exchange 2007 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:
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 is required for the change to propagate fully throughout the forest depends on the Active Directory replication topology and schedule as defined by site links.
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.
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.
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 2007 server. For more information about how Exchange 2007 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.
The default cost for a site link is 100. A valid site link cost can be any number from 1 to 99,999. If you specify redundant links, the link with the lowest cost assignment is always preferred.
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. Exchange 2007 considers only IP site links when it makes routing decisions. 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 do not have a reliable network link. An IP site link is not limited in the types of data that can be replicated across it. Exchange 2007 uses only IP site links to determine its routing topology. The cost that is assigned to the IP site link will be considered by the routing component of Exchange 2007 when calculating a routing table. These costs are used to calculate the least cost routing path to the ultimate destination for a message.
Note
An IP site link can also be assigned a schedule and a replication interval. Those attributes do not affect Exchange 2007 mail flow.
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 is part of an IP site link can communicate directly with every other site in that link at a uniform cost. An IP site link always enables communication between servers in both directions. If additional IP site links are not created, and all Active Directory sites are associated with the DEFAULTIPSITELINK, the effect is called a full mesh topology. A full mesh topology is a network architecture in which each network segment can reach any other network segment directly through a point-to-point physical or logical connection.
In Figure 2, 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.
Figure 2 Full mesh topology with a single IP site link
.gif "Full mesh topology with a single IP site link")
In Figure 3, 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.
Figure 3 Hub-and-spoke topology of Active Directory IP site links
.gif "Hub and spoke topology of IP site links")
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 2007, you must make sure that the current topology supports efficient messaging communication. 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 2007. 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.
Topology Discovery
The Exchange 2007 topology relies on the Active Directory site topology and does not have its own configuration. The Active Directory topology is made available to Exchange 2007 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 2007 server roles, except the Edge Transport server role. These Exchange 2007 servers use the Microsoft Exchange Active Directory Topology service to discover the domain controllers and global catalogs servers that can be used by the Exchange servers to read and write Active Directory data. Exchange 2007 binds to the identified directory servers whenever Microsoft 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:
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 2007 server roles deployed on those servers.
The data that is retrieved in step 1 is used to create the initial topology and to begin linking and mapping the related configuration objects.
Exchange servers are matched to Active Directory sites by retrieving the site attribute value from the Exchange server object that is stored in Active Directory.
Routing tables are updated with the collection of information retrieved.
This process makes every Exchange 2007 server aware of the other Exchange servers in the organization and of how close the Exchange servers to one another.
Exchange 2007 Routing Tables
When the Microsoft Exchange Transport service starts, it calculates a set of routing tables that is based on the snapshot of information that is retrieved from Active Directory or, on an Edge Transport server, from ADAM. The configuration information that is stored in ADAM includes available connectors and accepted domains, but does not 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 are 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. This includes Exchange 2007 foreign connectors and any non-SMTP connectors hosted by Exchange 2003 or Exchange 2000
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 2007 Hub Transport servers, Edge Transport servers, Mailbox servers, and Exchange 2000 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 2007 Hub Transport servers, Edge Transport servers, Mailbox servers, and Exchange 2000 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 Messages to Public Folders.
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 2007 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 it 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 are not 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\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 Managing Routing Table Logging.
Determining the Ultimate Destination
A message can be received by a Hub Transport server from any of the following sources:
An Edge Transport server that is relaying a message into the organization
Mailbox server submission
The Pickup directory or Replay directory
A Unified Messaging server
Internally generated system mail, such as a DSN
Another Hub Transport server
An Exchange 2003 or Exchange 2000 server
Foreign gateways submitting to the Pickup directory
Third-party SMTP servers
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 is not 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.
Non-SMTP gateway delivery The messages are queued for delivery to an external recipient by using a foreign connector for which the local server is a source server. This delivery type is used only when the messages are being delivered to the foreign connector drop directory on the local server.
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 is subscribed to the local Active Directory site.
MAPI delivery The messages are queued for delivery to a recipient's mailbox, a public folder, or a public folder store that is located on a Mailbox server that is located in the local Active Directory site.
SMTP relay in an Active Directory site The messages are queued for delivery to a Hub Transport server that is located in the same Active Directory site as the local server. The destination server can be the source server for a Send 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 is located in a remote Active Directory site. The destination server in the remote Active Directory site can be any of the following:
The source server for a connector that is configured to transport messages for external recipients
The source server for a routing group connector
A distribution group expansion server
A Mailbox server that is 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 is 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 or Exchange 2000 routing group. The 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
Unreachable A route to the recipient could not be determined and the messages are located in the Unreachable queue.
Determining the Least Cost Routing Path
When multiple routing paths exist to a destination, Exchange 2007 routing uses deterministic algorithms to select a single, deterministic routing path over which to route the message. 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 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. And 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 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.
The connector state The Exchange 2007 routing component only considers enabled connectors when it calculates the routing path. However, earlier versions of Exchange Server do not consider connector state. For more information, see Message Routing in a Coexistence Environment.
Connector scope A connector may be limited to use by Exchange 2007 servers that are located in the same Active Directory site as the source transport servers for the connector. In earlier versions of Exchange Server, 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 is 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 is closest, in this order: local server, server in the same Active Directory site, server in a remote Active Directory site or routing group.
As explained earlier, Exchange 2007 uses a deterministic algorithm to select the least cost routing path. The following logic is used to select the routing path:
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.
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.
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 to the destination is lowest in alphanumeric order is used. If the site nearest to the destination is the same for all routing paths being evaluated, an earlier site name is considered.
Figure 4 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.
Figure 4 An Exchange 2007 routing topology
.gif "Least cost route selection for Exchange routing")
Example 1 A message that is 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 ten. 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 2007 routing component does not consider alternative routing paths.
An Active Directory site that does not have any Hub Transport servers deployed is not recognized by routing and does not participate in Exchange topology. However, if such a site exists along the least cost routing path between sites where Hub Transport servers are deployed, the IP site link costs of the links connecting that site are considered in the least cost routing path calculation.
This section provides an overview of how the least cost routing path is determined. For detailed information about the selection of routing paths for specific mail flow scenarios, see the following topics:
Next Hop Selection
Exchange 2007 Hub Transport servers do not 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 happens.
Figure 5 shows a simple Exchange topology and illustrates many of the Exchange routing components.
Figure 5 Exchange topology and routing components
.gif "Topology and components used in next hop selection")
Using Figure 5 as a reference, a message that is sent from Mailbox1 in Site A, to the external recipient joe@contoso.com is processed as follows:
The Microsoft Exchange Mailbox Submission service that is running on Mailbox1 notifies a Hub Transport server that is located in the same Active Directory site of the new mail item for transport.
Using RPC, the store driver component on a Hub Transport server in the same Active Directory site retrieves the message and puts it in the Submission queue on the local server.
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.
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.
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.
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 is not 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 is the source server for the connector.
Table 2 provides additional examples of the next hop selection for several recipients based on the topology shown in Figure 5.
Table 2 Examples of next hop selection in Figure 5
| Receiving server | Ultimate destination | Next hop | Queue delivery type |
|---|---|---|---|
Hub1 |
Mailbox1 |
Mailbox1 |
MAPI delivery |
Hub1 |
Mailbox2 |
Site B |
SMTP relay to a remote Active Directory site |
Hub1 |
Mailbox3 |
Routing group connector 1 |
SMTP relay to a legacy routing group |
Hub1 |
Recipient@fourthcoffee.com |
Hub3 |
SMTP relay in an Active Directory site |
Hub1 |
Recipient@contoso.com |
Site B |
SMTP relay to a remote Active Directory site |
Hub2 |
Mailbox1 |
Site A |
SMTP relay to a remote Active Directory site |
Hub2 |
Mailbox2 |
Mailbox2 |
MAPI Delivery |
Hub2 |
Mailbox3 |
Site A |
SMTP relay to a remote Active Directory site |
Hub2 |
Recipient@contoso.com |
Send connector 2 |
DNS connector delivery |
Hub2 |
Recipient@fourthcoffee.com |
Site A |
SMTP relay to a remote Active Directory site |
Hub3 |
Mailbox1 |
Mailbox1 |
MAPI delivery |
Hub3 |
Recipient@fourthcoffee.com |
Send connector 1 |
Smart host connector delivery |
After the least cost routing path has been calculated and the next hop destination has been chosen, Exchange 2007 routing tries to relay the message directly to the destination. However, in some configuration scenarios, direct relay does not occur. For example, an Exchange administrator can configure an Active Directory hub site to force message delivery to relay through a particular Active Directory site in situations where direct communication between Active Directory sites is not possible because of network security or connectivity restrictions. For more information, see "Implementing Hub Sites" later in this topic.
A message that is being delivered to more than one recipient may also be relayed through an interim site. Exchange 2007 is designed to minimize network bandwidth usage. One feature of this design is the ability to delay generation of multiple copies of a message for delivery to recipients in different destinations until a fork in the delivery path is reached. This feature is known as delayed fan-out. For more information, see "Delayed Fan-Out" later in this topic.
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. In Exchange 2007, 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. This behavior is known as queue at point of failure. When the message is queued at the point in the delivery path where communication failed, this will help you determine why the message delivery failed.
In Figure 6, if a message is being delivered between Site A and 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. 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 recategorization after a default interval of 12 hours. Queues that have a connector as the next hop destination are not automatically resubmitted unless a configuration change that causes resubmission occurs. For more information, see Message Rerouting and the Unreachable Queue.
You can use the Exchange 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 Figure 6, a message is being sent from Site A for delivery to Site D. The Hub Transport servers in Site D are offline. Therefore, the message queues at Site C.
Figure 6 Queue at point of failure
.gif "Queue at point of failure")
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 Q is A - B - C - D - E - F - G - H - I - J - K - L - M - N - O - P- Q 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 Q. When the connection attempt fails, the next attempt is made to all Hub Transport servers in Site I. This is halfway to Site Q. When that connection attempt fails, the next connection attempt is made to all Hub Transport servers in Site E. This is halfway between Site A and Site I. When that connection attempt fails, connection attempts are made to Site D, Site C, and Site B because they are 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.
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 are 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 Exchange Management Shell tasks 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 is 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 are relayed to their ultimate destination. To set Site C as a hub site, run the following command in the Exchange Management Shell:
Set-AdSite -Identity "Site C" -HubSiteEnabled $true
After the least cost routing path is chosen, routing determines whether there is 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 are relayed to the target destination. If there is more than one hub site along the least cost routing path, messages stop at each hub site along the routing path.
You must understand that this variation to direct relay routing only is in effect when the hub site is located along the least cost routing path. Figure 7 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 are delivered to Site D.
Figure 7 Message delivery with a hub site
.gif "Message delivery with a hub site")
Figure 8 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 does not exist along the least cost routing path between any other sites, queuing at Site B before delivery to the destination does not occur. An Active Directory site is never used as a hub site if it is not on the least cost routing path between two other sites.
Figure 8 Misconfigured hub site
.gif "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.
Controlling IP Site Link Costs
As an Exchange administrator, you should work closely with the Active Directory administrator of your organization when you evaluate how the Active Directory site topology affects Exchange routing. Because Active Directory IP site links costs are based on relative network speed compared to all network connections in the wide area network, and are designed to produce a reliable and efficient replication topology, the existing IP site link costs should work well for Exchange 2007 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 are not optimal for Exchange 2007, you can make adjustments to the costs evaluated by Microsoft Exchange. As an Exchange administrator, you cannot and should not modify the cost assigned to the IP site link by using Active Directory tools. 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 Exchange Management 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. Otherwise, the Active Directory replication cost is used.
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. Figure 9 shows an Active Directory topology with four sites.
Figure 9 Topology with Exchange costs configured on IP site links
.gif "Topology with Exchange costs on IP site links")
In Figure 9, the network connection between Site C and Site D is a low bandwidth connection that is only used for Active Directory replication and should not 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.
New in Exchange 2007 Service Pack 1
Exchange 2007 Service Pack 1 (SP1) provides supports for configuration of a maximum message size limit on an Active Directory IP site link. By default, Exchange 2007 does not 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 is 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 How to Configure Message Size Limits for Internal Routing.
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:
Recipient resolution Each recipient of the message is resolved to a delivery destination.
Routing The least cost routing path for each recipient is determined. This includes whether a hub site is configured.
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 2007 compares the routing path for each recipient. To preserve bandwidth, the bifurcation, or splitting of the message into multiple copies, does not occur until a fork in the routing path is encountered.
For example, if multiple recipients of a single message share part of 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 Figure 10, 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.
Figure 10 Delayed message fan-out
.gif "68e0eaa9-e98d-4343-b1d9-61a51cf47484")
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 the configuration changes are processed and routing tables are recalculated. Messages are not rerouted in the following scenarios. Instead, a non-delivery report (NDR) is returned to the sender:
The recipient is a non-SMTP address and a matching connector for the address space cannot be found.
The message does not meet the message size restrictions of any matching connector.
The store driver resubmits the message for rerouting if the following conditions are true:
A message is in a MAPI delivery queue.
Between the time that the next hop was selected and the time that the message is ready to be delivered, the mailbox is moved to another Mailbox server.
During enhanced DNS resolution, routing tries to detect if a queue has to be rerouted. During 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 for rerouting.
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 is automatically detected. For more information about how messages are rerouted, see Message Rerouting and the Unreachable Queue.
For More Information
For more information, see the following topics: