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

4/28/2011 4:05:28 PM
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:

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.


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.


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.


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.


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.


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.


    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.

  •  Implementing Client Access and Hub Transport Servers : Installing the Client Access Server
  •  Implementing Client Access and Hub Transport Servers : Understanding the Client Access Server (part 2)
  •  Implementing Client Access and Hub Transport Servers : Understanding the Client Access Server (part 1)
  •  SharePoint 2010 : Implementing and Managing In Place Records
  •  Understanding Exchange Policy Enforcement Security : Creating Messaging Records Management Policies
  •  Understanding Exchange Policy Enforcement Security : Implementing Transport Agent Policies on the Edge
  •  Safeguarding Confidential Data in SharePoint 2010 : Using Active Directory Rights Management Services (AD RMS) for SharePoint Document Libraries
  •  Safeguarding Confidential Data in SharePoint 2010 : Enabling TDE for SharePoint Content Databases
  •  Safeguarding Confidential Data in SharePoint 2010 : Using SQL Transparent Data Encryption (TDE)
  •  Safeguarding Confidential Data in SharePoint 2010 : Enabling SQL Database Mirroring
  •  Safeguarding Confidential Data in SharePoint 2010 : Outlining Database Mirroring Requirements
  •  Remote Administration of Exchange Server 2010 Servers : RDP with Exchange Server 2010 (part 2)
  •  Remote Administration of Exchange Server 2010 Servers : RDP with Exchange Server 2010 (part 1) - Planning and Using Remote Desktop for Administration
  •  Remote Administration of Exchange Server 2010 Servers : Using the ECP Remotely
  •  Safeguarding Confidential Data in SharePoint 2010 : Examining Supported Topologies
  •  SharePoint 2010 : SQL Server Database Mirroring for SharePoint Farms
  •  Remote Administration of Exchange Server 2010 Servers : Using the Remote Exchange Management Shell
  •  Remote Administration of Exchange Server 2010 Servers : Certificates, Trust, and Remote Administration
  •  Enabling Presence Information in SharePoint with Microsoft Communications Server 2010
  •  Integrating Exchange 2010 with SharePoint 2010
    Top 10
    Nikon 1 J2 With Stylish Design And Dependable Image And Video Quality
    Canon Powershot D20 - Super-Durable Waterproof Camera
    Fujifilm Finepix F800EXR – Another Excellent EXR
    Sony NEX-6 – The Best Compact Camera
    Teufel Cubycon 2 – An Excellent All-In-One For Films
    Dell S2740L - A Beautifully Crafted 27-inch IPS Monitor
    Philips 55PFL6007T With Fantastic Picture Quality
    Philips Gioco 278G4 – An Excellent 27-inch Screen
    Sony VPL-HW50ES – Sony’s Best Home Cinema Projector
    Windows Vista : Installing and Running Applications - Launching Applications
    Most View
    Bamboo Splash - Powerful Specs And Friendly Interface
    Powered By Windows (Part 2) - Toshiba Satellite U840 Series, Philips E248C3 MODA Lightframe Monitor & HP Envy Spectre 14
    MSI X79A-GD65 8D - Power without the Cost
    Canon EOS M With Wonderful Touchscreen Interface (Part 1)
    Windows Server 2003 : Building an Active Directory Structure (part 1) - The First Domain
    Personalize Your iPhone Case
    Speed ​​up browsing with a faster DNS
    Using and Configuring Public Folder Sharing
    Extending the Real-Time Communications Functionality of Exchange Server 2007 : Installing OCS 2007 (part 1)
    Google, privacy & you (Part 1)
    iPhone Application Development : Making Multivalue Choices with Pickers - Understanding Pickers
    Microsoft Surface With Windows RT - Truly A Unique Tablet
    Network Configuration & Troubleshooting (Part 1)
    Panasonic Lumix GH3 – The Fastest Touchscreen-Camera (Part 2)
    Programming Microsoft SQL Server 2005 : FOR XML Commands (part 3) - OPENXML Enhancements in SQL Server 2005
    Exchange Server 2010 : Track Exchange Performance (part 2) - Test the Performance Limitations in a Lab
    Extra Network Hardware Round-Up (Part 2) - NAS Drives, Media Center Extenders & Games Consoles
    Windows Server 2003 : Planning a Host Name Resolution Strategy - Understanding Name Resolution Requirements
    Google’s Data Liberation Front (Part 2)
    Datacolor SpyderLensCal (Part 1)