If you would like to read the other parts in this article series please go to:
- SMTP Routing in Exchange 2010 (Part 1)
- SMTP Routing in Exchange 2010 (Part 2)
- SMTP Routing in Exchange 2010 (Part 4)
Introduction
In my previous two articles I explained a bit more about the SMTP Routing in the Exchange Server 2007 and 2010 Hub Transport Server Role. These articles were focused on only one Active Directory site. I’ll go into more details when multiple sites are involved.
Active Directory sites
Exchange Server 2003 used the concept of Routing Groups for routing SMTP messages, where Active Directory used the Active Directory sites for exchanging information. In Exchange Server 2007 this was combined and Routing Groups are no longer used and this is true for Exchange Server 2010 as well.
An Active Directory site is associated with one or more IP subnets. Exchange Servers are automatically assigned to a particular site as soon as their IP address is part of one of these subnets. Exchange Server is a so called “site aware” application, which means it has knowledge the site the Exchange Server is a member of, and when it needs services of another server or role (think of a Domain Controller or Global Catalog server) it queries its own site first for these services. Since Exchange Server is site aware it can also use the Active Directory topology for routing messages. It also uses the Active Directory topology for determining other Exchange servers in the same site, possibly with other Server Roles on it. The Active Directory site is the “service discovery boundary” which means the Exchange Server will not look outside its own Active Directory site for other Exchange Servers.
Site membership is determined with a series of DNS queries during startup of the server; the Netlogon service is responsible for this. When you check the DNS entries of your Active Directory you’ll see not only the standard A records but also service records. These service records are used to find other services in the Active Directory site. Site membership is determined by comparing the local IP address with information found in DNS. The Active Directory Topology service also queries Active Directory, by default every 15 minutes, to retrieve a list of Domain Controllers and Global Catalog Server in the Active Directory site. This information is written to the Application Eventlog:
Log Name: Application
Source: MSExchange ADAccess
Date: 24-1-2011 10:41:59
Event ID: 2080
Task Category: Topology
Level: Information
Keywords: Classic
User: N/A
Computer: EXCH01.infra.local
Description:
Process MAD.EXE (PID=2484). Exchange Active Directory Provider has discovered the following servers with the following characteristics:
(Server name | Roles | Enabled | Reachability | Synchronized | GC capable | PDC | SACL right | Critical Data | Netlogon | OS Version)
In-site:
DC01. infra.local CDG 1 7 7 1 0 1 1 7 1
DC02. infra.local CDG 1 7 7 1 0 1 1 7 1
Out-of-site:
AMS-DC01. infra.local CDG 1 7 7 1 0 1 1 7 1
AMS-DC02. infra.local CDG 1 7 7 1 0 1 1 7 1
Clearly visible: this Exchange Server has two Domain Controllers (and Global Catalog) in his site, and two other Domain Controller (and Global Catalog) in the Amsterdam Active Directory site.
Every Exchange Server has a property called msExchServerSite. This property is populated with the Distinguished Name of the Active Directory site the Exchange Server is a member of. The Active Directory Topology service is also responsible for populating this property.
Every site that has an Exchange Server 2010 Mailbox must have at least one Hub Transport Server and at least one Client Access Server in the same site. The Mailbox Server uses the Hub Transport Server to send messages to other Mailbox Servers in other sites. So the Mailbox Servers themselves never communicate with each other.
Suppose we have two Active Directory sites and each sites has a Mailbox Server, a Hub Transport Server and a Client Access Server (I’ve not drawn the CAS in this picture).
Figure 1: Direct delivery from one Active Directory site to another Active Directory site
User1 has a mailbox on MBX01 and he sends a message two User2 who has a mailbox on MBX02. When the message is sent it is picked up by HUB01, the categorizer on HUB01 determines where the recipient is located. User2 is in the same Active Directory, but in another site. Since HUB01 cannot communicate with MBX02 the message is sent to HUB02 in the 2nd site. On HUB02 the messages is stored in the submission queue, picked up by the categorizer and the categorizer determines that the message is a local delivery. The message is now stored in a delivery queue for MBX02 and the message is delivered in the correct mailbox.
Queue at point of failure
A sending Hub Transport Server always tries to connect to the corresponding Hub Transport Server in the other site directly. But when the receiving Hub Transport Server is not available, the sending Hub Transport Server tries to deliver the message as close as possible by determining a so called backoff path. By using the backoff path the Exchange Server tries to deliver the message as close as possible to the recipient’s Hub Transport Server.
Suppose a situation like this: HUB01 wants to send an SMTP message to HUB03 but unfortunately HUB03 is not available. HUB01 determines a backoff path where HUB02 is the next hop in the routing path. The message is delivered to HUB02 where it is queued. The queue will be in a retry state and will try to deliver following the retry settings. As soon as HUB03 is available again the message is delivered. If in the end the message cannot be delivered in a timely manner, the message will expire and an NDR will be sent back to the original sender. This mechanism is called “Queue at Point of Failure”.
Figure 2: Queue at point of failure. The message is queued on HUB02
Delayed Fan-Out
A typical message can contain not one, but maybe multiple recipient email addresses. Suppose a user in Site-1 wants to send a message to users in Site-3 and Site-4. The message is picked-up by Hub Transport Server HUB01. HUB01 tries to determine the most cost effective way to send all messages and it determines the routing path for each message (i.e. recipient). All routing paths are compared, and HUB01 sends a message to a point where the recipients can be split. This splitting is known as bifurcation in Exchange Server and bifurcation occurs at the point where the message is split.
So, HUB01 sends the message to HUB02 where bifurcation occurs. HUB02 sends a message to HUB03 and HUB04 where the messages will be delivered. This mechanism is called “delayed fan out”.
Figure 3: Delayed Fan-Out. The message is split on HUB02
Unreachable Queue
There’s one queue I haven’t mentioned so far, which is the unreachable queue. When Exchange isn’t able to determine a valid route for a given recipient the message is placed in the unreachable queue. When Exchange recalculates the routing table and a valid path is determined for this recipient the message will be sent. If no routing path can be determined, the message will expire and an NDR will be sent to the original sender.
Shadow Queue
When you check the queues on a Hub Transport Server using the Queue Viewer of the Get-Queue cmdlet you’ll see message stuck in a shadow queue. You’ll see these messages in this particular queue, even when the messages are successfully delivered.
Shadow queues are a new feature in Exchange Server 2010 which facilitates redundancy on the transport layer of SMTP messages, so it’s a Hub Transport Server feature. This is achieved by deleting sent messages from a queue after the next hop in transit has successfully delivered the SMTP message. If it’s not successful the Hub Transport Server will try to find another route to the final destination.
For example, a Hub Transport Server will send a message to another Exchange 2010 Server, in this example an Edge Transport Server. When the message is delivered to the Edge Transport Server, the Hub Transport Server will store the message in a shadow redundancy queue. The Edge Transport Server will deliver the message to another SMTP Server on the Internet. When the message is delivered, the message will be stored in a shadow redundancy queue on the Edge Transport Server. The Hub Transport Server will periodically poll the Edge Transport Server for successful delivery. If it is successful the message is deleted from the shadow redundancy queue on the Hub Transport Server.
Figure 4
If the Edge Server cannot deliver the message, the Hub Transport Server will know because of this polling. It will try another route and will send the message to the other Edge Transport Server.
In my next article I will explain a bit more about troubleshooting the message flow in an Exchange 2010 environment.
If you would like to read the other parts in this article series please go to:
