There’s quite a bit to write about regarding the changes to how messages are managed in Exchange 2013, so I’ve decided to post a separate article on the subject.
Notable Changes
There are several important things to note regarding how messages are routed in Exchange 2013:
- Message routing occurs on Mailbox Servers. With the removal of the Hub Transport role, all routing decisions are made by the Transport Service during message categorization. (See Part 1: Message Transport)
- Routing is fully DAG aware. Once a Mailbox Server is joined to a Database Availability Group (DAG), Exchange 2013 defines the DAG as a routing boundary. This makes sense if your DAG spans multiple Actie Directory Sites, since using the Active Directory Site as the primary routing boundary is inefficient. Servers that are not part of a DAG will continue to use an AD Site as a routing boundary.
- Only the Mailbox Transport service communicates directly with the mailbox database on the local Mailbox server. When the Mailbox server is a member of a DAG, only the Mailbox Transport service on the Mailbox server that holds the active copy of the mailbox database accepts the message for the destination recipient.
- The Mailbox Transport Service uses RPC when sending or receiving messages from the local mailbox database. All other forms of cross-server communication used to transfer messages in Exchange now relies on SMTP.
Routing Components
The routing function is now performed on the Mailbox Server in Exchange 2013. The routing process occurs once a recipient’s destination is identified by the message categorizer, a sub-component of the Transport Service. There are three components in the routing:
1. Routing Destinations
2. Delivery Groups
3. Queues
Routing Destinations: Are used in Exchange to define the ultimate destination for a message. These can be i) a mailbox database; ii) a SMTP Send connector or non-SMTP Delivery Agent or Foreign connector; or iii) a distribution group expansion server.
Delivery Groups: This is (an evolution of the routing group) and are collections of transport servers that are responsible for delivering messages to a particular routing destination. Transport servers can either be Exchange 2013 Mailbox servers or Exchange 2010 Hub Transport servers (only for routing destinations that are connectors and distribution group expansion servers).
The different types of Delivery Groups (DGs) are:
- Routable DAG DG: Group members are Mailbox servers in the same DAG, which functions as the group boundary. The routing destinations are the mailbox databases within the DAG. Messages are routed directly to the Mailbox Transport service on the server that hosts the active copy of the destination mailbox database, which delivers the message to the local mailbox database.
- Mailbox DG: Group members are Exchange servers of the same version in the same AD site. The routing destination depends on the version of Exchange that the mailbox database is located on.
Exchange 2010: For messages arriving at a random Exchange 2010 Hub transport
server in the destination AD site, the Store Driver uses RPC to write the message to
the mailbox database.
Exchange 2013: For messages arriving at an Exchange 2013 Mailbos server in the
destination AD site, the Transport service uses sMTP to transfer the message to the
Mailbox Transport service, which then uses RPC to write the message to the
mailbox database. - Connector source DG: Group members can be a mix of Exchange 2010 Hub Transport servers and Exchange 2013 Mailbox servers that are scoped as the source server for a SMTP Send connector or non-SMTP Delivery Agent or Foreign connector. The routing destination is the connector and only scoped servers are allowed to route messages to the destination defined by the connector.
- AD site DG: Group members can be can be a mix of Exchange 2010 Hub Transport servers and Exchange 2013 Mailbox servers that belong to the same AD site. Note in some cases the AD site may be used to traverse messages to their ultimate destination when i) The AD site is configured as a hub site and messages are relayed through the hub site to their ultimate destination, and ii) a legacy Exchange Edge Transport server is subscribed to the AD site and aren’t directly accessible from other AD sites.
- Server list DG : Group members are Exchange 2010 Hub Transport servers or Exchange 2013 Mailbox servers that are configured as distribution group expansion servers. The routing destination is the distribution group expansion server.
Note: Delivery group membership isn’t mutually exclusive. For example, an Exchange 2013 Mailbox server that’s a member of a DAG can also be the source server of a scoped Send connector. This Mailbox server would belong to the routable DAG delivery group for the mailbox databases in the DAG, and also a connector source server delivery group for the scoped Send connector.
Also, the Front End Transport service running on a Client Access server is never considered a member of a delivery group, even when the Mailbox server and the Client Access server are installed on the same physical server. This forces the Front End Transport service to communicate with the Transport service only.
Queues: A delivering server uses each delivery queue to represent the destination for a particular message. A receiving server performs message categorization queues a message for delivery. In each case, the NextHopSolutionKey attribute is used to denote the destination of each unique recipient and corresponds to a separate delivery queue.
The NextHopSolutionKey attribute contains three fields:
- Next Hop Type This is the target delivery group for message routed between delivery groups, or the routing destination for messages routed within a delivery group.
- Next Hop Domain This is the name of the queue target and depends on the value of the Next Hop Type field.
- Next Hop Connector This is an optional GUID value that depends on the value of the Next Hop Domain field.
Routing Behavior
Routing behavior can be classified by the three types of transport services:
A. Routing via the Mail Transport service
B. Routing via the Front End Transport service
C. Routing via the Mailbox Transport Service
A. Routing – Mail Transport Service
How the message is routed within an organization depends on the relationship between the source transport server and the destination delivery group:
I. Routing within the same delivery group: The routing destination itself is the next hop for the message. The message is delivered by the source transport server to the mailbox database or connector on a transport server in the delivery group†.
† Note that when a distribution group expansion server is the routing destination, the distribution group is already expanded by the time messages reach the routing stage of categorization on the distribution group expansion server. Therefore, the next hop routing destination from the distribution group expansion server is always a mailbox database or a connector.
II. Routing between delivery groups: The message is relayed along the least-cost routing path to the destination delivery group. Depending on the size and complexity of the Exchange topology, the message is relayed to other transport servers along the least cost routing path, or the message is relayed directly to a transport server in the destination delivery group.
Exchange 2013 uses the following logic to select the routing path for a message.
- Calculate the least-cost routing path by adding the cost of the IP site links 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, 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 before the destination is 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.
Because a delivery group may span multiple AD sites (DAG DG), there may be multiple least-cost routing paths to those multiple AD sites. A single AD site in the destination delivery group is designated as the primary site. The primary site is the closest AD site based on the routing logic above.
To successfully route messages between delivery groups, Exchange 2013 takes the following issues into consideration:
– Hub sites: If the least-cost routing path to the primary site contains any hub sites, the message must be routed through the hub sites. The closest hub site along the least-cost routing path is selected as a new delivery group of the type AD site, which includes all transport servers in the hub site. After the message traverses the hub site, routing of the message along the least-cost routing path continues. If the primary site happens to be a hub site, the primary site is still considered a hub site for the following reasons:
- If the destination delivery group spans multiple Active Directory sites, the source server should only attempt to connect to the servers in the hub site.
- The servers in the hub site that actually belong to the target delivery group are preferred.
- As in previous version of Exchange, any hub sites that aren’t in the least-cost routing path to the primary site are ignored.
– Target destination server: When the destination delivery group spans multiple Active Directory sites, the routing path to specific servers within the delivery group may have different costs. Servers located in the closest Active Directory site are selected as the target servers for the delivery group based on the least-cost routing path, and the Active Directory site those servers are in is selected as the primary site.
– Fallback options: If the destination delivery group spans multiple Active Directory sites, the first fallback option is all other servers in the destination delivery group in other Active Directory sites that aren’t selected as target servers. Server selection is made based on the cost of the routing path to those other Active Directory sites. If the destination delivery group has any servers in the local Active Directory site, there are no other fallback options because the message is already as close to the target routing destination as possible. If the destination delivery group has servers in remote Active Directory sites, the option is to try to connect to all other servers in the primary site. If that fails, a backoff path in the least-cost routing path to the primary site is used. Exchange 2013 tries to deliver the message as close to the destination as possible by backing off, hop by hop, along the least-cost routing path until a connection is made.
B. Routing – Front End Transport service
This service acts as a stateless proxy for all inbound and outbound external SMTP traffic for the Exchange 2013 organization.
I. Outbound: Outbound messages are relayed to the Front End Transport service via Send connectors (SMTP) from the Transport service running on Exchange 2013 Mailbox servers. Any Front End Transport service in a local Active Directory site can be used to proxy all outgoing messages for the site by configuring the FrontEndProxyEnabled parameter in the Exchange Management Shell or by selecting the Proxy through Client Access server option in the Send connector properties from the EAC.
II. Inbound: Routing in the Front End Transport service resolves message recipients to mailbox databases. The list of Mailbox servers used by the Front End Transport service is based on the mailbox databases of the message recipients. Note that it’s possible that none of the recipients have mailboxes, for example, if the recipient is a distribution group or a mail user. For each mailbox database, the Front End Transport service looks up the delivery group and the associated routing information from Routing tables that are loaded based on information from Active Directory. The delivery groups used by the Front End Transport service are:
- Routable DAG
- Mailbox delivery group
- AD site
Note that the routing tables don’t contain any Send connector routes.
Depending on the number and type of recipients, the Front End Transport service performs one of the following actions:
- For messages with a single mailbox recipient, select a Mailbox server in the target delivery group, and give preference to the Mailbox server based on the proximity of the Active Directory site. Routing the message to the recipient may involve routing the message through a hub site.
- For messages with multiple mailbox recipients, use the first 20 recipients to select a Mailbox server in the closest delivery group, based on the proximity of the Active Directory site. Note that message bifurcation doesn’t occur in Front-End Transport, so only one Mailbox server is ultimately selected, regardless of number of recipients in a message.
- If the message has no mailbox recipients, select a random Mailbox server in the local Active Directory site.
C. Routing – Mailbox Transport Service
This service comprises of the Mailbox Transport Submission service and Mailbox Transport Delivery service.
I. Inbound: the Mailbox Transport Delivery service receives SMTP messages from the Transport service, and connects to the local mailbox database using RPC to deliver the message.
The Mailbox Transport Delivery service has the option to accept or reject the message for delivery to a local mailbox database. The Mailbox Transport Delivery service can deliver the message if the recipient resides in an active copy of a local mailbox database. But, if the recipient doesn’t reside in an active copy of a local mailbox database (ie. it was recently moved to another server), the Mailbox Transport Delivery service can’t deliver the message, and must provide a non-delivery response to the Transport service. The non-delivery responses that the Mailbox Transport Delivery service returns to the Transport service include:
- Retry delivery
- Generate an NDR
- Reroute the message
II. Outbound: the Mailbox Transport Submission service connects to the local mailbox database using RPC to retrieve messages, and submits the messages over SMTP to the Transport service. The Mailbox Transport service is stateless, and doesn’t queue any messages locally. Because the Transport service and the Mailbox Transport service exist on the same Exchange 2013 Mailbox server, the Mailbox Transport service always belongs to the same delivery group as the Mailbox server. This delivery group is referred to as the local delivery group. Also, the Mailbox Transport submission service can send messages to the Transport service on other Exchange 2013 Mailbox servers outside the delivery group.
Steps when a user sends a message:
Let’s see what happens when a user sends a message from their mailbox
1. The Mailbox Transport Submission service resolves the message recipients to mailbox databases.
2. The list of Mailbox servers is based on the mailbox databases of the message recipients.
3. For each mailbox database, the Mailbox Transport Submission service looks up the delivery group and the associated routing information. The delivery groups used by the Mailbox Transport Submission service are:
- Routable DAG
- Mailbox delivery group
- AD site
4. Depending on the number and type of recipients, the Mailbox Transport Submission service performs one of the following actions:
- Messages with a single mailbox recipient: select a Mailbox server in the target delivery group, and give preference to the Mailbox server based on the proximity of the Active Directory site.
- Messages with multiple mailbox recipients: use the first 20 recipients to select a Mailbox server in the closest delivery group, based on the proximity of the Active Directory site.
- If the message has no mailbox recipients, select a Mailbox server in the local delivery group.
Hi all, I hope that you got some useful information on how Exchange 2013 routes messages. I’m probably going to come back to this at some date (once Exchange 2013 RTMs) and clean up this section.
Ook, Road Chimp, signing off!