A Word about MEC 2012
Microsoft recently held a Microsoft Exchange Conference (MEC) for the first time in ten years. My next few blog posts will cover lessons learned. The purpose of this particular conference was to introduce Exchange 2013 to the Exchange community and provide a forum where we could interface with Exchange product managers, program managers, and developers. The content depth delivered at MEC cannot be found anywhere else. However, the true value of the conference for me was rubbing elbows with the Exchange Team, Exchange Masters, Exchange MVPs, and fellow IT professionals. One of the most enlightening conversations I had during the conference was with a program manager about being on-call for Office 365 support. I had no idea that the Exchange Team literally supports the Office 365 environment and receives automated voice messages when something breaks inside Exchange Online. Not surprisingly, Exchange 2013 reflects a sharper focus on fault detection and recovery with its Managed Availability features. Nothing will motivate a developer to solve a problem like getting phone calls at 3:00 a.m. Hopefully, we won’t have to wait another ten years for the next MEC. During the closing keynote address, Michael Atalla, Director of Product Management for Exchange, said there will be another MEC when the Exchange Team “has something interesting to say.” I personally would like there to be a MEC next fall to compare notes from the field on Exchange 2013 and drill into Service Pack 1 improvements.
Exchange 2013 Simplifies Roles
One of the most striking changes in Exchange 2013 is its simplification of roles. In general, Information Technology trends tend to be cyclical. For example, we started off with dumb terminals back in the mainframe days, then moved to thick client personal computers, and are now going back to thin clients with VDI. In Exchange 2000 and 2003, there were essentially two server roles: front-end and back-end. Since Exchange 2007, server role architecture has been split up into five roles: (1) Hub Transport; (2) Client Access; (3) Mailbox; (4) Unified Messaging; and (5) Edge Transport. In Exchange 2013, the architecture has been changed to consolidate the roles down to two again: Client Access and Mailbox. You may be wondering, have we returned to the old front-end/back-end architecture from the last decade? The answer is yes and no.
The traditional Client Access functions in Exchange 2013 are found in the Client Access Front-End or “café” as it is referred to by the Exchange Team. Client Access servers provide authentication, redirection, and proxy services for Outlook, Outlook Web App, ActiveSync, POP3, and IMAP4 connections to Exchange 2013 mailbox servers. However, unlike Exchange 2007 and 2010, this role does not leverage IIS to render any data. That responsibility has shifted back to the Mailbox role, which now runs IIS with all the Exchange Web Service virtual directories like the back-end servers in Exchange 2000 and 2003. All connections between the Client Access and Mailbox servers are stateless. There is no longer a need to maintain session affinity or “stickiness” between a client and a particular Client Access server for subsequent connections because all data rendering and transformation occurs on the mailbox server. This means that load balancers no longer need the advanced application layer (layer 7) capabilities required by Exchange 2007 and 2010. They simply need to evenly distribute traffic between Client Access servers at the layer 4 level.
With only two roles in Exchange 2013, the obvious question is: “Where did the Hub Transport role go?” The answer is that it has been folded into the Client Access and Mailbox roles as a series of services. TechNet describes these services as follows:
Front End Transport service – This service runs on all Client Access servers and acts as a stateless proxy for all inbound and outbound external SMTP traffic for the Exchange 2013 organization. The Front End Transport service doesn’t inspect message content, but it can filter messages based on connections, domains, senders, and recipients. The Front End Transport service only communicates with the Hub Transport service on a Mailbox server, and doesn’t queue any messages locally.
–
Transform your business operations with our Microsoft solutions
Explore Our Microsoft Consulting Services →
–
Hub Transport service – This service runs on all Mailbox servers and is virtually identical to the Hub Transport server role in previous versions of Exchange. The Hub Transport service handles all SMTP mail flow for the organization, performs message categorization, and performs message content inspection. Unlike previous versions of Exchange, the Hub Transport service never communicates directly with mailbox databases. That task is now handled by the Mailbox Transport service. The Hub Transport service routes messages between the Mailbox Transport service, the Hub Transport service, and the Front End Transport service.
Mailbox Transport service – This service runs on all Mailbox servers and consists of two separate services: Mailbox Transport Submission service and Mailbox Transport Delivery service. The Mailbox Transport Delivery service receives SMTP messages from the Hub Transport service and connects to the mailbox database using an Exchange remote procedure call (RPC) to deliver the message. The Mailbox Transport Submission service connects to the mailbox database using RPC to retrieve messages and submits the messages over SMTP to the Hub Transport service. The Mailbox Transport service doesn’t queue any messages locally.
Figure 1. – Exchange 2013 transport pipelinei
In Exchange 2013, each routing destination has a collection of transport servers that are responsible for delivering messages to that routing destination. These collections are called delivery groups, which sounds very similar to routing groups in Exchange 2000 and 2003. However, delivery group membership is less rigid than routing groups. Delivery groups can be made up of Exchange 2013 mailbox servers that belong to one Database Availability Group (DAG), Exchange 2013 mailbox servers + Exchange 2010 Hub Transport servers in an Active Directory site, or Exchange 2013 mailbox servers + Exchange 2010 Hub Transport servers scoped to a connector. The difference is that these delivery group memberships are not mutually exclusive. Unlike routing groups in Exchange 2000 and 2003, a server can be a member of multiple delivery groups.
So, what is the Exchange Team’s rationale for “dumbing down” the Client Access role to a stateless proxy and moving so much of Exchange’s functionality into the Mailbox role? Flexibility. In Exchange 2007 and 2010, Client Access, Hub Transport, and Mailbox roles had to adhere to site boundaries because they relied on latency sensitive RPC connections to communicate with each other (TCP port 135 + 1025-65535). Exchange 2013 servers encapsulate all RPC traffic inside of HTTPS just like Outlook Anywhere. Consequently, the new Client Access role only proxies HTTPS and SMTP traffic to the Mailbox role and can do so across slower WAN links. This decoupling of server roles gives architects much greater flexibility in designing Exchange 2013 deployments. For example, an organization could have a single unified namespace for all Exchange clients across the globe. One site could be designated as the single point of entry for client traffic (and for messaging traffic) and only have Client Access servers in it. These Client Access servers could then proxy/redirect Exchange client traffic anywhere in the world.
What about the Unified Messaging (UM) and Edge Transport roles? The UM role has been merged with the Mailbox role. At this time, there is not an Exchange 2013 version of the Edge Transport role. Exchange Team presenters at MEC stated that they simply ran out of development time to get Edge Transport out the door for Exchange 2013 Preview/RTM releases. Edge Transport is probably the least used Exchange role, so it is not surprising that it was at the bottom of the Exchange Team’s list of priorities. The unofficial expectation is that it will be available with Service Pack 1. In the meantime, Exchange 2010 Edge Transport servers can be used in front of Exchange 2013 Client Access servers.
In many ways it does seem like Exchange has gone back to the future with simplified front-end and back-end server roles. The difference is the Exchange 2013 version does not require these roles to be grouped together in geographic silos, meaning any Client Access server can proxy to any Mailbox server regardless of location. So the Exchange Team has managed to make the product easier to deploy and more robust at the same time. I wonder how they might go back to the future for future releases. Maybe in Service Pack 1 they will bring back the GWART…
Are you considering an Exchange migration and need additional information or real world expertise? Credera has extensive experience in designing, planning, and implementing messaging solutions. If you have questions about this blog post, points of view, or IT infrastructure, please contact us.
i TechNet, Exchange Server 2013 Mail Flow
Contact Us
Ready to achieve your vision? We're here to help.
We'd love to start a conversation. Fill out the form and we'll connect you with the right person.
Searching for a new career?
View job openings
