Exchange Server 2010 : Implementing Client Access and Hub Transport Servers - Understanding the Hub Transport Server

The Hub Transport server is part of the internal Exchange Server infrastructure. The Hub Transport server role handles all internal mail flow, applies transport rules and journaling policies, and delivers mail to the Mailbox server role for placement in the user’s mailbox. It also receives Internet mail from the Edge Transport server role, though the Hub Transport can also be configured to receive mail directly from the Internet. It is the evolved form of the bridgehead server in Exchange Server 2003, which was really the name of a configuration rather than a specific server component. The Hub Transport server has been developed to provide a number of key features that Exchange Server customers have long been clamoring for, such as disclaimers and transport rules.

The Hub Transport server provides four major services:

• Mail flow

• Categorization

• Routing

• Delivery

These services can collectively check mail for any problems such as spam or viruses, check mail for appropriateness, append any information that the organization needs, and finally route mail to the correct destination. New to Exchange Server 2010 is the Shadow Redundancy feature, which ensures delivery of messages by retaining a shadow copy and verifying delivery before releasing the shadow copy.

There should be a Hub Transport server in every AD site where there is a mailbox server for mail to flow and route correctly. Additional Hub Transport servers can be deployed for fault tolerance and load balancing, especially when paired with an Edge Transport server.

Mail Flow

The Hub Transport server is responsible for processing all mail that is sent within an Exchange Server 2010 organization. There is no exception to this. This allows the Hub Transport server to accomplish its other functions, such as categorization and routing.

It is important to understand that there are no exceptions to this rule. Thus, all mail flows through the Hub Transport servers. This ensures that the features that Hub Transport servers provide, such as transport rules, disclaimers, and journaling, are applied uniformly across the entire Exchange Server 2010 infrastructure.

Categorization

The categorizer does all the address lookups, route determination, and conversion of the content of messages. It is at this stage that the various agents, such as the transport rules agent and the journaling agent, process mail as well. It determines where the messages are destined to and what transport rules and journaling policies apply to the messages.

Although antispam and antivirus protection is provided by default at the Edge Transport server role, the Hub Transport server role can also be optionally configured to perform the scanning. This would take place at the categorization stage as well.

Routing

The Hub Transport server determines the path to route mail to. This applies to all messages that are not destined for mailbox servers in the local site. Messages that are destined for a mailbox server that is in another AD site are routed to a Hub Transport server in that site, whereas messages destined for external recipients are routed to Edge Transport servers.

Microsoft Exchange Server 2010 is AD site aware and uses the AD site topology for routing internally. It computes the most efficient—that is, lowest cost—route based on the sites and site links that it reads from Active Directory.

Note

It is critical to define the sites and the subnets that are associated with the sites for Exchange Server 2010 to route mail properly. These are fundamentally Active Directory design and deployment tasks, but not having it done properly can result in incorrect routing of email.

This is true for all Active Directory–aware applications, such as Exchange Server 2010, System Center Configuration Manager (SCCM), distributed file system (DFS), and even Active Directory itself. Without a properly designed and deployed site and subnet infrastructure, they will fail or perform inefficiently.

The Hub Transport servers are intelligent and understand the architecture of the network based on the information in the sites and IP site links. If a message is destined for two different recipients, the Hub Transport servers will delay bifurcation of the message until the last possible hop.

This is illustrated in Figure 1. The user Chris in San Francisco sends a message to Sophia and Mike, who are in different locations (London and Frankfurt) and, thus, in different AD sites. A single message is routed through the transport from San Francisco to New York until it reaches Paris, which is the last possible hop for the message to split. The Paris Hub Transport server then bifurcates the message and sends one to London and one to Frankfurt.

Figure 1. Message bifurcation.

Delivery

If the categorizer determines that the recipient of the messages is on a mailbox server in the local AD site, the message is delivered directly to the mailbox server.

Shadow Redundancy

The Shadow Redundancy feature in Exchange Server 2010 gives message routing a fault tolerance capability. The concept behind shadow redundancy is that a message is not deleted from the queue until the next hop has confirmed delivery to the subsequent hop. If confirmation is not received, the message is resubmitted. If the next hop server is down, the message is resubmitted to another server.

Note

Assured delivery requires that there be redundant Hub Transport and Edge Transport servers to resubmit to if a failure of any given transport server occurs.

The components of the shadow redundancy follow:

• Primary Message— The original message submitted to transport for delivery.

• Shadow Message— The copy of a message that a transport server retains until it confirms that all the next hops for that message have successfully delivered it.

• Primary Server— The transport server that is currently processing a message.

• Shadow Server— The transport server that holds shadow copies of a message after delivering the message to the primary server.

• Shadow Queue— The queue that a transport server uses to store shadow messages. A transport server will have separate shadow queues for each primary server to which it delivered the primary message.

• Discard Status— The information a transport server maintains for shadow messages that indicates when a message is ready to be discarded.

• Discard Notification— The response a shadow server receives from a primary server indicating a message is ready to be discarded.

• Shadow Redundancy Manager— The transport component that manages shadow redundancy.

• Heartbeat— The process of transport servers verifying the availability of each other.

A mail flow with shadow redundancy is given in the following example. In the example, Chris with mailbox on Exchange Server 2010 mailbox server MB1 is sending a message to Michelle with a mailbox on Exchange Server 2010 mailbox server MB2. There are two Exchange Server 2010 Hub Transport servers: HT1 and HT2. The process is as follows:

1. Chris submits message— The message is submitted to MB1. MB1 becomes the primary server for the message.

   Note

   Client submissions such as MAPI, Windows Mobile, or SMTP client are not redundant until the message is successfully stored on the mailbox or hub transport server. Then the Exchange Server high-availability features take effect.

   
   

2. MB1 submits to HT1— The message is submitted by MB1 to HT1. HT1 becomes the primary server and MB1 becomes a shadow server. However, HT1 subsequently fails and never acknowledges the delivery of the message to MB2. MB1 times out and becomes the primary server.

3. MB1 submits to HT2— The message is resubmitted by MB1 to the redundant HT2. HT2 becomes the primary server and MB1 becomes a shadow server.

4. HT2 submits to MB2— The message is submitted to by HT2 to MB2. MB1 confirms that HT2 has delivered the message, deletes the message from its shadow queue, and is no longer a shadow server.

5. Michelle receives message— The message is received by Michelle.

The process is diagrammed in Figure 2.

Figure 2. Shadow Redundancy example.

Shadow redundancy gives the Exchange Server 2010 self-healing capabilities for mail flow. It enables the infrastructure to intelligently fail over between redundant paths if messages have not been delivered in a timely manner.