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 two; the Client Access server and the Mailbox server.
The questions that follow are usually along the lines of:
- How does the mail flow work without a Hub Transport server?
- Where did the Edge Transport server go?
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 provides filtering of email traffic (eg antispam agents), and routing of email between the internal Exchange servers and the outside world
The Mailbox server role hosts two additional services:
- Hub 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 Hub 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 Server 2013 Mail Flow – Source: TechNet
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.exchange2003demo.com.
The message headers look like this (I’ve truncated the data that is not relevant to this topic):
Received: from MB2.exchange2013demo.com (192.168.0.188) by MB2.exchange2013demo.com (192.168.0.188) with Microsoft SMTP Server (TLS) id 15.0.466.13; Tue, 31 Jul 2012 21:52:45 +1000 Received: from MB2.exchange2013demo.com (192.168.0.188) by MB2.exchange2013demo.com (192.168.0.188) with Microsoft SMTP Server (TLS) id 15.0.466.13; Tue, 31 Jul 2012 21:52:43 +1000 Received: from MB2.exchange2013demo.com ([fe80::9ca9:e0d9:ec3a:996b]) by MB2.exchange2013demo.com ([fe80::9ca9:e0d9:ec3a:996b%12]) with mapi id 15.00.0466.010; Tue, 31 Jul 2012 21:52:42 +1000
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.
Received: from HO-EX2010-MB2.exchangeserverpro.net (10.1.1.22) by HO-EX2010-MB1.exchangeserverpro.net (10.1.1.21) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 31 Jul 2012 22:22:07 +1000 Received: from HO-EX2010-MB1.exchangeserverpro.net ([fe80::d957:3403:56cf:a8cb]) by HO-EX2010-MB2.exchangeserverpro.net ([fe80::f148:390:568f:38dc%16]) with mapi id 14.02.0309.002; Tue, 31 Jul 2012 22:22:03 +1000
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
- Hub 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:
451 4.7.0 Temporary server error. Please try again later. PRX3
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.
I suspect the solution to this is to continue pointing to the Mailbox server’s Hub Transport service for device/application SMTP requirements, not the Client Access server as you might assume from its default Receive Connector configuration.
Exchange Server 2013 Edge Transport Server?
So if the Exchange 2013 Client Access server is pre-configured for the internet-facing transport role, where does that leave the Edge Transport role?
For starters, there is no Edge Transport role in the Exchange 2013 Preview, and Microsoft has stated that Edge Transport will not ship with Exchange 2013 RTM.
Whether it will ship with a later service pack or not at all is still an unknown, but there has been speculation that the Edge Transport server role will not exist in future.
In the meantime you can use Exchange Server 2013 with Exchange 2007/2010 Edge Transport servers.
Interestingly the guidance from Microsoft if not using EdgeSync is to establish SMTP connectivity between the Edge Transport server and the Exchange 2013 Mailbox server, which means that I’m currently doing it “wrong” in my own lab by routing the email from Edge Transport to Exchange 2013 Client Access.
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.
No comments:
Post a Comment