Pro-Exchange,Lync & Office 365
Belgian Microsoft Unified Communications Professionals
Microsoft Exchange Server, Microsoft Lync Server & Office 365
What happened to the Hub Transport Server role in Exchange Server 2013?

Exchange 2013 introduced some changes to the core architecture compared to Exchange Server 2010. One of the changes is that the Hub Transport Role is now no longer available as a separate server role. However, this doesn’t mean that the components have disappeared though.

In fact, the Transport Pipeline from Exchange 2010 has been pulled apart into three pieces:

  • Front-End Transport Service (FET)

  • Hub Transport Service (HT)

  • Mailbox Transport Service (MT)

Front End Transport Service

This services resides on Client Access Server. Because a CAS is now no more than a proxy, the transport service will not perform any scanning actions or queuing of messages. However, it can perform some basic filtering tasks like:

  • Connection Filtering

  • Recipient/Sender Filtering

  • Domain Filtering

Basically, the FE Transport Service is able to reject messages before accepting them into the Exchange organization. Once a messages has been accepted, the FE Transport Service will forward the message to the Hub Transport Service using SMTP:


Depending on how your environment looks like, the CAS will select a Hub Transport server based on different criteria, including it's location relative to the CAS and the Recipient(s). For more information on this process, have a look at

Hub Transport Service

This is the part of the transport pipeline that looks almost the same as in Exchange Server 2010. The Hub Transport Service acts as a “man-in-the-middle” that handles messages from/to the Front End Transport Service and the Mailbox Transport Service and it is also the only transport service to perform content scanning and queuing of messages.

The Hub Transport Service, now residing in the Mailbox Server role, is (amongst others) responsible for:

  • Message Categorization (Routing decisions)

  • Content Inspection

The Hub Transport Service is also the place where Transport Rules & -Agents are applied.

The difference with Exchange 2010 is that the Hub Transport service cannot communicate directly with the mail store. Before, the Hub Transport Service would try to communicate to the mailbox using RPC traffic but now, it will forward the messages to the Mailbox Transport Service or Hub Transport Service located on another server using SMTP:


Depending on where a mailbox is located, it will deliver the message to the local Mailbox Transport Service, or one located on another mailbox server. If, however, the target Mailbox resides on a Mailbox Server that is member of another DAG, the Hub Transport service will deliver the message to another Hub Transport Service in the remote DAG.

Mailbox Transport Service

The Mailbox Transport service runs on all Mailbox servers and consists of two separate services:

  • Submission Service

  • Delivery Service

As the names might already give away, the Delivery Service is responsible for delivering messages to mailboxes using RPC after having received them from the Hub Transport Service over SSMTP (TCP465). The Submission Service on the other hand will retrieve messages from mailboxes using RPC and forward (submit) them to the Hub Transport service over SMTP. As is the case with the Front End Transport Service, the Mailbox Transport Service doesn’t queue messages locally:


Putting it all together

When putting the information from above together, we get the following result (image from: Microsoft TechNet)

Transport pipeline overview diagram

Transport Rules

The way transport rules are applied hasn’t changed, one of key changes in Exchange Server 2013 is that Transport Rules are now invoked on “onResolvedMessage” instead of on “onRoutedMessage". This means that Transport Rules can now effectively be used to require TLS for certain messages. Although this change might not be the most ground-breaking news, it does opens up some possibilities.

For more information on what else has changed for Transport Rules, have a look here.

High Availability Improvements

Along with some of the key architectural changes, the Transport Pipeline also contains some rather nice improvements towards High Availability:

  • Messages are made redundant before reception is acknowledged to the sender

  • Stretched DAGs automatically create site resiliency for transport

  • Resubmits (after a failover event) are handled automatically

The way it works is as follows:


  1. A message is sent to the Hub Transport Service on MBX-01.
  2. MBX-01 will create a Shadow Copy of the message, by creating a shadow SMTP session with another Hub Transport (MBX-03) within the same DAG. If the DAG stretches multiple sites, a Hub Transport in the other AD site is automatically chosen.
  3. The remote Hub Transport (MBX-03) will acknowledge to MBX-01 that the message has been queued locally
  4. Only after having received the acknowledgement from MBX-03, MBX-01 will return a 250 OK back to the sender.

What if we make things more complicated?

Image the scenario above, but this time, the message is sent to multiple recipients, located across multiple DAGs and AD sites:


  1. A message is sent to the Hub Transport Service on MBX-01.
  2. MBX-01 will create a shadow copy of the message on a Hub Transport within the same DAG, located in another AD Site. At the same time, a copy of the message is send to a Hub Transport in the second DAG.
  3. Once the message has been placed in it’s shadow queue, MBX-03 will acknowledge the creation of the shadow copy to MBX-01
  4. MBX-05 will also try to create a shadow copy with another Hub Transport that is member of the same DAG, if one exists also in another AD Site (MBX-07)
  5. Once the message has been placed in it’s shadow queue, MBX-07 will acknowledge the creation of the shadow copy to MBX-05
  6. Now that MBX-05 has received the acknowledgement of MBX-07, it will acknowledge receipt to MBX-01
  7. Only after having received acknowledgement from MBX-03 and MBX-05; MBX-01 will return a 250 OK to the sender.


Although the Hub Transport Server Role is no longer available, it’s legacy lives on in both remaining roles. Along with some of the key architectural changes, Microsoft managed to squeeze in some other improvements with regards to management (Transport Rules) and High Availability. Especially the improvements regarding High Availability are welcome as they make designing a highly available, site resilient Exchange environment a bit easier.

Posted 07-18-2012 2:21 by Michael Van Horenbeeck