At first glance, many Exchange 2013 improvements appear similar to the evolutionary changes we saw in Exchange...
2007 to Exchange 2010. But, that's not the case, especially when it comes to server roles. Unlike the two previous versions, Exchange 2013 ships with just two server roles: the mailbox server and the client access server. Nowhere are the under-the-hood changes more revolutionary than in the client access server role.
The Exchange Server 2007 and Exchange 2010 iteration of the client access server (CAS) role was meant to address CPU scalability limits present in the hardware market when Exchange 2007 was being designed and released. By breaking storage, transport and client handling functionality into separate roles, Microsoft intended for Exchange 2007 to be spread across servers that were configured according to the appropriate workload. Microsoft continued this trend in Exchange 2010 by moving the MAPI-RPC over TCP endpoint to the CAS role and introducing client access server arrays.
However, these design changes introduced their own problems:
Because communication among the core roles was all in remote procedure call (RPC), they were tightly coupled and dependent on the Active Directory site structure and inter-site latency. Therefore, they had to be present in all Exchange mailbox sites.
Exchange servers had to be upgraded in a specific sequence to ensure that client data rendering did not break. Even though the CAS role was primarily responsible for data rendering, core APIs and functions were still spread out.
Exchange Server became more complicated to deploy, as namespace and certificate planning required more endpoints.
Exchange servers -- especially in regards to Exchange 2010 -- became dependent on hardware load-balancing products that could provide sophisticated, level seven session persistence capabilities.
Even though the hardware market caught up with Exchange, many customers still deployed Exchange servers that wasted CPU and expansion capability.
With Exchange 2013, Microsoft has re-mapped its architectural goals to the current state of the hardware market and Exchange 2010 deployment guidelines.
Multi-role boxes are the most economical way to take full advantage of server consolidation capabilities. Additionally, removing complexity from the configuration helps Microsoft drive more successful customer deployments.
As a result, the Exchange 2013 CAS role has been reborn:
All client data rendering or processing has moved to the mailbox server role. In Exchange Server 2013, the actual protocol endpoints live in services on the mailbox role. The CAS role -- though still in the protected network and a member of the domain -- is now a smart proxy that contains enough logic to authenticate the incoming connection and determine which mailbox server to proxy the connection to.
Client access traffic does not use uses RPC-based protocols. Even in Exchange 2010, Outlook clients would bypass client access arrays and servers to connect to public folders if using MAPI-RPC over TCP. Exchange 2013 no longer supports direct MAPI-RPC over TCP connections; all client connections are handled via Outlook Anywhere (RPC over HTTPS), other Web protocols, or legacy fallbacks (POP3, IMAP and SMTP).
Outbound SMTP may also be routed through Exchange 2013 client access servers. Additionally, with this change, a mailbox server can be at a higher service pack than the CAS.
All client access traffic is now stateless. Incoming HTTPS, SMTP, POP3 and IMAP connections are passed through to the mailbox server in real time. Because there is no longer client-access-to-mailbox RPC, proxy connections only require state and queuing on the mailbox server role; this is where the users' actual data lives. If a CAS goes offline, another will take its place without affecting the users' connections.
Load balancing and namespace planning are both simpler and more scalable. Because the mailbox server is now the protocol endpoint, the CAS no longer needs to terminate SSL sessions and insert cookies. As a result, load balancing is now done at layer four, allowing both the CAS and load balancer to scale to higher degrees. Fewer DNS namespaces are required -- in many cases only two -- and a single global unified namespace becomes a realistic design goal.
An Exchange 2013 CAS proxies across site boundaries and protocols are more resilient to inter-site network latencies. This means that in some deployments, client access servers will only be required in Internet-facing sites. If you use unified messaging, however, be aware that incoming connections must connect to the unified messaging call routing service on a CAS. They are then redirected to the appropriate mailbox server.
This new architecture is a radical departure from past versions of Exchange Server. By directly addressing the design goals of improved simplicity, scalability and availability, the Exchange 2013 CAS role plays a key part in helping Exchange Server 2013 deliver a better user experience while also simplifying administration.
About the author:
Devin Ganger is a messaging architect and technical writer with more than 15 years of experience in administering messaging systems, 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.