Exchange Server 2016 builds upon the architecture introduced in Exchange Server 2013, with the continued focus goal of improving the architecture to serve the needs of deployments at all scales.
In Exchange Server 2016, there is a single building block that provides the client access services and the high availability architecture necessary for any enterprise messaging environment.
In our continuing quest to improve the product’s capabilities and simplify the architecture and its deployment, we have removed the Client Access server (CAS) role and added the client access services to the Mailbox role. Even without the CAS role, the system maintains loose coupling in terms of functionality, versioning, user partitioning and geographical affinity.
The Mailbox server role now:
No clients connect directly to the back-end endpoints on the Mailbox server; instead, clients connect client access services and are routed (via local or remote proxy) to the Mailbox server that hosts the active database that contains the user’s mailbox.
Mailbox servers can be added to a Database Availability Group (DAG), thereby forming a high availability unit that can be deployed in one or more datacenters. DAGs in Exchange Server 2016 do have a few specific enhancements:
Removal of the separate CAS role does not affect how communication occurs between servers. Communication between servers still occurs at the protocol layer, effectively ensuring that every server is an island. For a given mailbox’s connectivity, the protocol being used is always served by the protocol instance that is local to the active database copy.
The load balancer configuration is also not affected by this architectural change. From a protocol perspective, the following will happen:
The protocol used in step 6 depends on the protocol used to connect to client access services. If the client request uses HTTP, then the protocol used between the servers is HTTP (secured via SSL using a self-signed certificate). If the protocol used by the client is IMAP or POP, then the protocol used between the servers is IMAP or POP.
Telephony requests are unique. Instead of proxying the request at step 6, the Mailbox server will redirect the request to the Mailbox server hosting the active copy of the user’s database, as the telephony devices support redirection and need to establish their SIP and RTP sessions directly with the Unified Messaging services on the Mailbox server.
Now many of you may be thinking, wait how does authentication work? Well for HTTP, POP, or IMAP requests that use basic, NTLM, or Kerberos authentication, the authentication request is passed as part of the HTTP payload, so the Client Access services within each MBX server will authenticate the request naturally. Forms-based authentication (FBA) is different. FBA was one of the reasons why session affinity was required for OWA in previous releases of Exchange – the reason being that that the cookie used a per server key for encryption; so if another MBX received a request, it could not decrypt the session. With Exchange 2013, we stopped leveraging a per server session key and instead leveraged the private key from the certificate that was installed on the Client Access server. With Exchange 2016, we now leverage the organization certificate that is configured for the organization’s authorization configuration. This means that any Exchange 2016 server can decrypt the cookie.
And yes, the Edge Transport server role will ship in Exchange Server 2016 (and at RTM, to boot!). All the capabilities and features you had in the Edge Transport server role in Exchange Server 2013, remain in Exchange Server 2016.
The Exchange Server 2016 architecture evolves the building block architecture that has been refined over the course of the last several releases. With this architecture, all servers in the Exchange environment (excluding Edge Transport) are exactly the same—the same hardware, the same configuration, and so forth. This uniformity simplifies ordering the hardware, as well as performing maintenance and management of the servers.
As with Exchange 2010 and in Exchange 2013, we continue to recommend role co-location as a best practice. From a cost perspective, the overall goal is to ensure that the architecture is balanced for CPU and disk. Having separate server roles can result in long-term cost disadvantages as you may purchase more CPU, disk, and memory resources than you will actually use. For example, consider a server that hosts only the Client Access server role. Many servers enable you to add a given number of disks in a very economical fashion—when you are deploying and using that number of disks, the cost is essentially zero. But if you deploy a server role that uses far less than the given number of disks, you’re paying for a disk controller that is either under-used or not used at all.
This architecture is designed to enable you to have fewer physical Exchange servers in your environment. Fewer physical servers mean lower costs for a variety of reasons:
This architecture ultimately distributes the load across a greater number of servers than deploying single-role servers because all Mailbox servers also handle client access because:
Exchange Server 2016 also includes a number of architectural improvements, beyond the server role consolidation, including search enhancements, document collaboration improvements, and more.
(scheduled for a future CU): One of the challenging areas for on-premises environment was the amount of data that was replicated with each database copy in previous releases. In Exchange Server 2016, we have reduced bandwidth requirements between the active copy and a passive copy by 40%. This was accomplished by enabling the local search instance to read data from its local database copy. As a result of this change, passive search instances no longer need to coordinate with their active counterparts in order to perform index updates.
Another area of investment in search has been around decreasing the length of time to return search results, especially in online mode clients like OWA. This is accomplished by performing multiple asynchronous disk reads prior to the user completing the search term, which populates the cache with the relevant information, providing sub-second search query latency for online mode clients.
In previous releases of Exchange, OWA included document preview for Office and PDF documents, reducing the need to have a full fidelity client. SharePoint 2013 had a similar feature, however it used the Office Web Apps Server 2013 (now rebranded as Office Online Server) to accomplish this capability. Within Office 365, we also leverage Office Online Server to provide this capability, ensuring uniform document preview and editing capability across the suite.
In Exchange Server 2016, we leverage Office Online Server to provide the rich document preview and editing capabilities for OWA. While this was a necessary change to ensure a homogenous experience across the Office Server suite, this does introduce additional complexity for environments that don’t have Office Online Server.
The next generation of Office Online Server will not be supported for co-location with Exchange. Therefore, you must deploy a separate server farm infrastructure. This infrastructure will require unique namespaces, and will require session affinity to be maintained at the load balancer.
While Exchange supports an unbound namespace model, the Office Online Server will require a bound namespace for each site resilient datacenter pair. However, unlike the bound namespace model within Exchange, Office Online Server will not require any namespace changes during a datacenter activation.
What about Exchange Web Services (EWS)? All existing applications that leverage EWS will continue to work with Exchange Server 2016. We are, however, focusing new platform investments on the REST APIs and the apps for Office extensibility model. We expect to make significantly fewer investments in EWS so that we can focus our resources on investing in a single modern API that will, over time, enable most of the scenarios that our partners currently use EWS.
Introduced in Exchange Server 2013 Service Pack 1, MAPI/HTTP is the new standard in connectivity for Outlook. In Exchange Server 2016, MAPI/HTTP is enabled by default. In addition, Exchange Server 2016 introduces per-user control over this connectivity model, as well as, the ability to control whether the protocol (and Outlook Anywhere) is advertised to external clients.
Note: Exchange Server 2016 does not support connectivity via the MAPI/CDO library. Third-party products (and custom in-house developed solutions) need to move to Exchange Web Services (EWS) or the REST APIs to access Exchange data.
In Exchange Server 2013, the Client Access server role is simply an intelligent proxy that performs no processing/rendering of the content. That architectural tenet paid off in terms of forward coexistence. When you introduce Exchange Server 2016, you do not need to move the namespace. That’s right, the Exchange Server 2013 Client Access infrastructure can proxy the mailbox requests to the Exchange 2016 servers hosting the active database copy! For the first time ever, you get to decide when you move the namespace over to the new version. And not only that, you can even have load balancer pools contain a mix of Exchange Server 2013 and Exchange Server 2016. This means you can do a one-for-one swap in the load balancer pool – as you add Exchange 2016 servers, you can remove Exchange 2013 servers.
Exchange Server 2016 will only be supported on Windows Server 2012, Windows Server 2012 R2 and Windows Server 2016 operating systems.
From an Active Directory perspective, Exchange Server 2016 will require:
Exchange Server 2016 will only support coexistence with Exchange Server 2010 SP3 RU11 and Exchange Server 2013 CU10.
During my session at Microsoft Ignite, I revealed Microsoft’s preferred architecture (PA) for Exchange Server 2016. The PA is the Exchange Engineering Team’s best practice recommendation for what we believe is the optimum deployment architecture for Exchange 2016, and one that is very similar to what we deploy in Office 365.
While Exchange 2016 offers a wide variety of architectural choices for on-premises deployments, this architecture is our most scrutinized one ever. While there are other supported deployment architectures, they are not recommended.
The Exchange 2016 PA is very similar to the Exchange 2013 PA. A symmetrical DAG is deployed across a datacenter pair with active database copies distributed across all physical servers in the DAG. Database copies are deployed on JBOD storage, with four copies per-disk. One of the copies is a lagged database copy. Clients connect to a unified namespace that is equally distributed across the datacenters in the site resilient pair.
However, the Exchange 2016 PA differs in the following ways:
For more information, please see the Exchange 2016 Preferred Architecture article.
Exchange Server 2016 continues in the investments introduced in previous versions of Exchange by reducing the server role architecture complexity, aligning with the Preferred Architecture and Office 365 design principles, and improving coexistence with Exchange Server 2013.
These changes simplify your Exchange deployment, without decreasing the availability or the resiliency of the deployment. And in some scenarios, when compared to previous generations, the PA increases availability and resiliency of your deployment.. Technology FAQs