Under the hood: Microsoft Exchange 2016 deployment architecture

by Akfash Latibu [Published on 27 April 2017 / Last Updated on 27 April 2017]

Are you on board with Microsoft Exchange Server 2016 yet? Released in the fourth quarter of 2015, Exchange 2016 brings with it significant changes in its deployment architecture. But before we get into these changes, let’s take a brief look at how the popular mail, calendar, and contacts service has evolved.

 From the initial release of Microsoft Exchange Server 4.0 more than 20 years ago to the recent release of Exchange Server 2016, many new features, performance enhancements, and most importantly, architectural changes have been introduced. In addition to changes in the deployment architecture, over the last 10 to 15 years, from Exchange Server 2003 until Exchange Server 2016, there have been changes in the management consoles, which have moved from the standard Microsoft Management Console to a web-based management portal.

Exchange 2003 deployment architecture

Microsoft Exchange 2003 had two basic roles in its deployment architecture: frontend and backend, just like its predecessors. Technologies such as failover clustering, DNS round-robin, and network load balancing were then used as high availability option within Microsoft Exchange Server 2003. When Microsoft released MS Exchange 2007, the architecture was totally revamped with a mandatory requirement of an x64 Windows server, and the product was split across five different server roles due to CPU constraints. The server roles were mailbox, hub transport server role, client access server role, unified messaging server role, and edge transport server role. All these roles had their own high availability methods. A few years after this, Microsoft Exchange Server 2010 was released, and the roles remained the same.

Exchange 2013 deployment architecture

With the release of Microsoft Exchange Server 2013, there were some changes in terms of the architecture of the product. With the enhancements in CPU power that took place since the previous version, several server roles were combined. Exchange 2013 had only three roles: mailbox, client access and edge. The hub transport and unified messaging server roles, which existed in the previous versions, were merged with the mailbox server role. Although during the initial release of MS Exchange 2013 the edge server role was not present, Microsoft introduced the edge functionality with the release of MS Exchange server 2013 Service Pack 1.

Exchange 2016’s architectural changes


MS Exchange 2016 added some further architectural changes. The server roles were again consolidated. MS Exchange 2016 has only two server roles, namely mailbox and edge server. The client access server roles present in the previous version is consolidated with the mailbox server role and is installed automatically along with the mailbox. This eliminates the possibility of installing it separately. Apart from this there are some improvements in search as MAPI over HTTP is set as the default protocol used for Outlook connections. Both these server roles are managed by the Exchange administration center as well as the exchange management shell.

The mailbox server is responsible for storing and containing the mailbox databases in which all the user mail boxes, resource mailboxes, and other mailbox types and content are stored. It also contains the transport services, which were in other server roles previously. These transport services route emails to the relevant destination based on the delivery addresses.

Exchange Server 2016 mailbox servers can be configured with the database availability group (DAG) to make it highly available. DAG was introduced as one of the high available options in MS Exchange Server 2010 and has been improved in the 2016 version. DAG is a collection of mailbox servers that replicates the mailbox databases among each other. This provides the ability to automatic database level recovery from any sort of disaster.


With MS Exchange Server 2016, a DAG can comprise up to 16 mailbox servers. This is like having 16 copies of a single mailbox dataset saved across your network. Within the mailbox server, there are other high availability features that one can configure targeting the transport service. Features such as shadow redundancy and safety net exist to serve this purpose. The client access server role, which is now merged with the mailbox server role, exists in the form of client access services within the mailbox server. Client access services are the first set of services that accepts client connections. That is when users connect to their mailboxes through Outlook, OWA, or any other type of clients; the initial connection is between the client and the client access services, which then sends the connection to the relevant backend services within the same or remote mailbox server to initiate the connectivity to retrieve data from the mailbox.

Edge transport servers are optional, but it is highly recommended to deploy them. Edge servers are responsible for Internet mail flow and are used to set rules and block spam. Since edge servers are to be deployed in the DMZ or the perimeter network, the server never becomes a member of the company’s active directory domain. Rather it uses the Microsoft Exchange EdgeSync to initiate a one-way communication with the Active Directory (AD) to the AD Lightweight Directory Services (AD LDS). Through this process the necessary AD information is synched with the edge server. It is recommended to deploy multiple edge servers to provide redundancy and high availability.

Requirements for using Exchange 2016

Similar to other server products, MS Exchange also has a list of system requirements. If there are older versions of Exchange that coexist with Exchange 2016, older versions should be Exchange 2010 SP3 or later. MS Exchange can only be deployed in an Active Directory environment and thus all domain controllers within the Active Directory forest should be Windows Server 2008 or above. The server on which MS Exchange is to be installed should be x64 architecture-based with adequate RAM and storage. This tool can be used to calculate the role requirements. As for the operating system requirement to install Microsoft Exchange 2016, Windows Server 2012 or above are supported. If Windows Server 2016 is used, the latest version of Microsoft Exchange Server 2016 with Cumulative Update 3 or above must to be used.

See Also

See Also