close
IC618048

As people learn about the new features of Exchange Server 2013 one of the first surprises is often the reduction in server roles to just three; the Client Access server, Mailbox server, and Edge Transport server.

The question that follows is usually asking how does the mail flow work without a Hub Transport server?

Exchange Server 2013 Transport Services

The Hub Transport server role from Exchange 2007 and 2010 has been replaced with a series of services running on the remaining server roles.

The Client Access server role hosts the Front End Transport service, which acts only as a proxy for SMTP connectivity.

The Mailbox server role hosts two additional services:

  • Transport service – performs email routing within the organization, and between the Front End transport service and the Mailbox Transport service
  • Mailbox Transport service – passes email messages between the Transport service and the mailbox database

There are some additional scenarios for the Mailbox server’s Transport services when Database Availability Groups are deployed, but for the moment we’ll just consider non-DAG scenarios.

Microsoft has published this diagram that gives a good visual representation of how these components all fit together. But if you find it a little confusing simply read on for a few practical examples.

exchange-2013-transport-architecture

Internal Mail Flow Example

Let’s take a look at an internal mail flow example for Exchange Server 2013. In this case the sender and recipient are both on the same mailbox database on the same server, MB2.exchange2013demo.com.

The message headers look like this (I’ve truncated the data that is not relevant to this topic):

Running the header through the MX Toolbox header analyzer gives us this visual representation.

Exchange Server 2013 Internal Mail Flow Example

What we see are three hops all on the same Mailbox server MB2.exchange2013demo.com, as the message travels through each of the services involved.

Exchange 2013 Internal Mail Flow Hops

Now compare that to an email sent between two Exchange Server 2010 recipients on the same mailbox database.

 

Exchange Server 2010 Internal Mail Flow Example

 

This time we only see two hops in the message headers.

Exchange Server 2010 Internal Mail Flow Hops

The best way I can think to describe this difference is that instead of message submission occurring directly via RPC/MAPI between the mailbox database and a Hub Transport server in Exchange 2010, it now traverses the intermediary Mailbox Transport service adding at the very least one additional SMTP hop in the message headers.

You will also note that the example for Exchange Server 2013 demonstrated that the Client Access server’s Front End Transport service was not involved for internal mail flow.

External Mail Flow Example

Now let’s take a look at an external mail flow example, specifically an email from the internet to a mailbox on an Exchange Server 2013 server.

Exchange Server 2013 External Mail Flow Example

The first three hops relate belong to Google, and the two that are obscured are another SMTP service involved in this particular mail flow path but not relevant to the Exchange behaviour.

The first Exchange server is an Exchange 2010 Edge Transport, which is configured to route the email to the Exchange 2013 Client Access server CA1.exchange2013demo.com, which then routes it on to the Mailbox server MB1.exchange2013demo.com.

Exchange Server 2013 External Mail Flow Hops

As you can see the Client Access server role in Exchange 2013 performs mail routing for external emails, but not internal emails. And once again we can see in the final hop MB1 -> MB1 as the message is passed between the Hub Transport service and the Mailbox Transport service on that server.

Default Receive Connector for Incoming Internet Email

Unlike Exchange 2007 and 2010 Hub Transport servers which were not configured by default to accept incoming email from the internet, when an Exchange 2013 Client Access server is installed it is pre-configured with a Receive Connector named “Default Frontend <servername>” that allows “Anonymous Users” to connect.

Exchange Server 2013 Frontend Receive Connector

So where Exchange 2007/2010 were secured by default and required the administrator to either deploy Edge Transport servers, or reconfigure the Hub Transport to perform the internet-facing role, Exchange Server 2013 Client Access servers are configured by default for the internet-facing role.

Exchange Server 2013 Message Queues

One of the interesting things about the three transport services in Exchange Server 2013 is that only one of them will actually queue messages locally.

  • Front End Transport service – no local queuing
  • Transport service – local queuing
  • Mailbox Transport service – no local queuing

To test this out I simply stopped the Hub Transport service on my Exchange 2013 server, and then used Telnet to send a test email message via the Front End Transport service.

After completing my commands in the Telnet session I received this error:

If another email server was sending the email message it would likely queue on that server until it was able to retry and successfully submit the message. However I would anticipate that some mail-enabled devices and applications will not handle this situation very well and it may lead to message failure if there is no high availability and load balancing deployed.

Exchange Server 2013 Edge Transport Server

The Edge Transport role was shipped in Exchange Server 2013 Service Pack 1. Ready more about installing and configuring Exchange 2013 Edge Transport here.

It is also possible to use Exchange Server 2013 with Exchange 2007/2010 Edge Transport servers.

Summary

As you can see the mail flow for Exchange Server 2013 is not that different to that in previous versions of Exchange once you shift your mindset from the server roles in previous versions to the specific services involved in Exchange Server 2013 mail flow.

Additional reading:

Abdulsalam Garba

The author Abdulsalam Garba

Leave a Response