Though the hub transport server role was officially retired in Exchange 2013, the modified server role architecture actually improves transport. Here's how.
What do you think is the most important Exchange Server role?
If you took a survey of Exchange administrators, the most popular answer would be the information store, as most time is spent on mailbox database design during Exchange deployment planning. Client-access namespaces and certificates also eat up a big chunk of the pie, while client configuration and third-party accessories are in the mix as well.
Those are all well and good, but in my mind, the real secret sauce is the hub transport server role. Transport actually moves messages from sender to recipient. Without transport, you don't have email. Instead, you have an anal-retentive database and a website with multiple personality disorder. The simple fact that transport works most of the time is evidence as to how awesome it really is.
Transport is still under the hood
Exchange Server 2013 only has two roles: the mailbox server role and the
Relax, Microsoft has you covered. Take a close look at Figure 1.
Figure 1. Transport services are still a major part of Exchange 2013.
If Mark Twain had been an Exchange administrator, he might have said, "Reports of the hub transport server role's demise have been greatly exaggerated." While Exchange 2013 transport has gone underground, you can see that it's far from gone.
In accordance with the design principles of Exchange 2013, the hub transport server role was broken up into multiple pieces and placed where they would do the most good.
The classic hub transport service that we all know -- and some of us love -- lives on in the mailbox server role. The Transport Service (Microsoft Exchange Transport in Figure 1) handles all inbound Simple Mail Transfer Protocol sessions from other servers, all outbound SMTP sessions with down-level Exchange hub transports and also outbound SMTP sessions to both Exchange 2013 mailbox and CAS servers.
The Transport Service handles all content conversion, transport agents and the categorizer. It is also the only one of the three transport services that will queue mail, meaning that only mailbox servers can be bridgeheads for Send connectors.
Although the Transport Service lives on in the mailbox server role, there is no guarantee that outbound messages from active mailbox databases on a given mailbox server will be sent through the Transport Service on the same server.
Up to this point, this behavior is the same as in previous versions of Exchange. What's different, though, is that the Transport Service is a valid delivery target for submitted messages from other Exchange 2013 mailbox servers in different sites -- a distinct difference from previous versions.
Mailbox Transport Service
In Exchange Server 2013, the mailbox server role is the final arbiter of all mailbox data; all communications with other servers and clients in the Exchange organization are through standard protocols. The only RPC connections are between components on the same server. The Mailbox Transport Service is the interface between RPC sessions with the Information Store and SMTP sessions with the standard Transport Service.
If you look back to Figure 1, you can see that the Mailbox Transport Service is actually not a single service. Messages coming from the Managed Store are handled by the Mailbox Transport Submission Service, while messages destined for the store are handled by the Mailbox Transport Delivery Service. Neither service creates queues, both are stateless, and both of these services can talk to the Transport Service on other Exchange 2013 mailbox servers via SMTP.
The Mailbox Transport Submission Service makes routing decisions to deliver submitted messages to a Transport Service instance in the target delivery group; these SMTP sessions can be directed to mailbox servers in other sites. If the properties of the message recipients permit, this optimization means that messages only need to transit through a single Transport Service instance.
The Frontend Transport Service
The Frontend Transport Service lives on the CAS role. It's less of a transport service and more of an SMTP proxy. If the CAS role is deployed, the Frontend Transport Service has modified routing tables so it can quickly proxy incoming SMTP sessions from external systems to the Transport Service on the mailbox server that holds the active copy of the database where the recipient's mailbox resides.
Outbound sessions to external systems originate on the Transport Service of the bridgehead mailbox server of the matching Send connector. If the FrontEndProxyEnabled property on the connector is set to "True," this SMTP session also gets proxied through the CAS role to the destination server. No specific client access server in the site is selected; they are all stateless.
These changes may be mystifying at first, but they're all designed to create a more robust Exchange organization. Through reduction of the number of hops, use of latency-sensitive RPC connections with resilient SMTP sessions over LAN and WAN links, and intelligent changes to the routing and queuing mechanisms, Exchange 2013 continues to reduce the risk and impact of service outages and while also ensuring that mail keeps flowing.
About the author
Devin Ganger is a messaging architect and technical writer with more than 15 years of experience in administering messaging systems and Windows, Unix and TCP/IP networks. Today, he works primarily with Exchange Server, Windows Active Directory and related Microsoft and third-party technologies. Ganger was recognized as a Microsoft MVP for Exchange Server from 2007 to 2011.
This was first published in April 2013