Exchange 2016 Architecture

While Exchange 2016 release date is still far in time and information available subject to change in this post I will describe what is known so far and the key enhancement Microsoft is going to implement in the new Exchange release

Exchange 2016 – Architecture

Exchange 2016 architecture is based on the fundamentals that have been laid out with Exchange 2013 even if Microsoft’s focus is to further consolidate roles to make deployments even simpler, the new architecture is depicted in the picture below courtesy of MS Technet:

Exchange 2016 Architecture

As probably you’ve noticed in Exchange 2016 the CAS (Client Access Role) is gone as client access services have been integrated into the Mailbox Server role, even with this new architecture no client ever connects directly to the back-end endpoints on the Mailbox Server instead clients connect to the client access services and are routed via a local or remote proxy to the Mailbox Server that has an active copy of the data the user needs to access.

Probably you’re wondering how the removal of the CAS role affects server to server communications, well short answer it doesn’t here’s another picture (again courtesy of MS Technet) that illustrates this concept:

Exchange 2016 Communications

As you can see in the picture above communications still happens at the protocol level in terms of mailbox protocol connectivity requests are always served by the protocol instance local to the active database the client is connecting to.

With the removal of the CAS Server role what changes when a Load Balancer is being used? Well answer again is “not much”, communication flow goes like this:

  • A client resolves the namespace (for example
  • The load balancer assigns the session to one of the Mailbox Servers defined in the LB pool
  • The request is authenticated by the Mailbox Server which also access Active Directory to retrieve information like Mailbox version (Exchange 2013, 2016 etc.) and mailbox location (database info, external URL etc.)
  • The connection can be either proxied or redirected to another mailbox server
  • The mailbox server queries to the Active Manager responsible for the database to determine the active database copy (I give for granted DAG is being used)
  • Finally request is proxied by the Mailbox Server to the Mailbox server hosting the active database copy

I think this is better expressed through another picture that does a better job than I did in explaining the whole process/flow:

Exchange 2016 Load Balancer

As you can see in the picture UM traffic takes a different route but I will leave that out for the moment as it deserves a dedicated post

Exchange 2016 – What has been improved?

Now that we have gone through the new Exchange 2016 architecture you are probably wondering what has been improved/changed in addition to the new architecture and the role consolidation.

Exchange 2016 Improvements – Search

Microsoft has invested into making searches more responsive and quicker to return results, this maybe was not so obvious when using Office 365 but has been often an issue with on-premises deployments.

Another area of enhancement has been the amount of data replicated between DAG members and the bandwidth required which has been reduced, according to Microsoft, of around 40%, this has been accomplished enabling local search instance to read data from its local database copy, this means passive copies don’t need anymore to synch with the active copy when an index update is taking place.

While we cannot yet test the new replication model and verify if the 40% is a real figure I’m rather confident improvements made in this area will indeed reduce traffic and load in DAG scenarios.

Exchange 2016 Improvements  – Coexistence with Exchange 2013

In Exchange 2013 the CAS role/job is basically to route traffic and render content for the client this means that when you introduce Exchange 2016 in your infrastructure no changes are needed. I repeat as it will seem too good to be true, when you install Exchange 2016 no changes to Exchange 2013 infrastructure are needed as the CAS can render content and route mailbox access traffic to an Exchange 2016 Mailbox server.

Best yet? If you have a Load Balancer with a pool of servers you can even have a mix of Exchange 2013 and Exchange 2016 servers! You are in control here, you can decide when you move the namespace over the new Exchange version (this really seems too good to be true!).

Exchange 2016 Improvements  – Outlook Connectivity

With Exchange 2013 SP1 Microsoft introduced MAPI/HTTP as a new Outlook protocol in Exchange 2016 this will be enabled by default and no action from your side will be needed.

Exchange 2016 Improvements – Collaboration and Document Management

In Exchange 2010/2013 Microsoft introduced support for Office and PDF files so that users could preview these files without having a full client. In Office 365 users have experienced this and the ability to edit files via Office Web Apps, similarly to what happens within SharePoint, same model and capabilities will be implemented within Exchange 2016.

Unfortunately this will introduce a further layer of complication as the Office Web Apps server cannot be co-located with the Exchange 2016 Server so you will have to deploy an extra server in the infrastructure, furthermore if your deployment is making use of multiple data centers you will be forced to use what is known as bound namespace as while Exchange 2016 supports unbound namespace Office Web Apps server does not you can see this below:

Exchange 2016 Office Web Apps


While personally I don’t like the introduction of the Office Web Apps Server component I think was a necessary evil to align On-Premises Exchange deployments with the Office 365 ones nonetheless I am eager to try this new release as many of the enhancement that have been implemented will solve a lot of issues many Exchange admins had to deal with.

Removal of the CAS server Role is a big step forward in simplifying the Exchange architecture but also in uniform configuration of the different servers, without all servers will have same code, same (or very similar) hardware configuration and so on, this new approach will make the environment even more resilient as it can suffer the loss of an arbitrary number of “CAS” servers.

What are your thoughts about the new Exchange 2016 Server? Are you eager to implement it or, as many others around the world, think it is just a funny name for Exchange 2013 SP2?

Be sure to check out the Exchange 2016 page all one stop shop for information and posts about Exchange 2016!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s