Exchange 2013 vs Exchange 2016 RTM

Before we get down to the nitty-gritty of Exchange 2016, let’s take a brief look at the legacy Exchange servers. Exchange 2000/2003 were very simple models in terms of functionality and offerings. You would rely on 3^rd party solutions integration for high availability and redundancy. All administration and management was performed through GUI and there were many limitations around deployment, configuration and automating task, nothing quite existed like what we call today “PowerShell”.

Exchange 2007 was a rather revolutionary edition of Exchange. HA and redundancy came on-board with the introduction of continuous replication. Separation of roles was easy to understand for management and deployment prospective. This was the very first time that “PowerShell” made its way through. Most hated it for what they call it was a scripting language or something but very quickly we started to fall in love with it. Since then PowerShell has been enhanced greatly and is being used on majority of the Microsoft’s platforms and applications.

Microsoft took “High Availability” to the next level with the release of Exchange 2010. “Database Availability group” (DAG) was introduced in addition to other improvements at the CAS and HUB level.

Where Exchange 2007 and Exchange 2010 had so much to offer, at the same time they came with additional difficulties and complexities with deployment process. Load balancing CAS servers has not only been a cumbersome process but you were also required an expensive layer 7 load balancing solution as well. Smaller to medium enterprises and even large enterprises could not invest in unless you were a multi-tenant hosted solution provider or something.

Then comes the Exchange 2013 with some major under the hood architecture changes. Microsoft consolidated the Exchange server roles and this is due to inexpensive and more powerful CPUs available today as they were back in old days. This left us with two Exchange roles, mailbox server role and client access server role. CAS server role became a stateless proxy server and all client activity and rendering was happening at the mailbox server role level.

This two level building blocks eased the management and deployment process at all scales from hosted solutions providers, large/small organisations to office 365 hybrid. Now there aren’t many arguments left for separating out CAS roles and you are no longer required to use expensive layer 7 solutions instead a layer 4 hardware load balancer will happily suffice your redundancy requirements.

Now here comes the Exchange 2016. Some people would say that Exchange 2016 looks like a service pack 2 for Exchange 2013.It may feel and look that way but under the hood there are important changes and improvements which I feel is necessary for us to understand.

Let’s first compare how Exchange 2016 differs from 2013 before we can go deeper into architecture changes and improvements with Exchange 2016. As it is RTM version, future releases will include new features and improvements and this has been tradition with Exchange for some time now. Take a look at this visual diagram to compare Exchange 2013 with Exchange 2016 RTM.

Figure 1.2 Exchange 2016 Server Role Architecture

Other than further consolidation of server roles we would expect a further improved hardware efficiency, much simplified, easier patching, upgrading and deployment process.
There are improvements both at the DAG and CAS level. When creating a DAG, “DatabaseAvailability GroupIPAddress” is no longer required. By default, the failover cluster will be created without an administrative access point, as this is the recommended best practice.
We saw faster database failover time Exchange 2013 SP1 but this to be further improved by another 33% in future cumulative updates and service packs of Exchange 2016.

The removal of CAS role has not affected the simplified name space deployment and layer 4 hardware load balancer will remain a preferred and cost effective choice when it comes to load balancing CAS traffic. Exchange 2016 now also allows you to proxy traffic from 2013 to 2016. This will ease migration process and also eliminates the need of deploying additional front-end infrastructure capacity to serve new Exchange 2016 servers.

Communication between servers occurs at the protocol layer, for example EWS will only talk to EWS with its partner server. Client access service do not perform any rendering rather it just provides client access protocol for authentication, limited redirection and proxy whereas mailbox server handles all the client activity for the active mailboxes it is hosting.

Other Architecture Improvements

Outlook on the Web (Formerly known as OWA) user interface is updated and optimised for tablets and smart phones enhance end user experience. MAPI over HTTP is now the default protocol for outlook to communicate Exchange 2016 and is enabled by default for new Exchange organisations. Any clients which do not support MAPI over HTTP will fall back to RPC over HTTP (Outlook Anywhere). It is more likely that future versions of Exchange may not include RPC over HHTP.
The improved document collaboration we have seem with Exchange online and SharePoint online will be shipped with Exchange 2016.Exchange 2016, along with SharePoint 2016 (currently in preview) will support modern attachments which means Exchange users will be able link and share to documents stored in OneDrive in an on-premises SharePoint server rather than the attachment themselves.
The hybrid configuration wizard (HCW) included with Exchange 2013 has now become a separate downloadable application and multi-forest hybrid deployment are being simplified with Azure AD Connect. Also there new and updated message policy and compliance features in Exchange 2016 for example DLP supports new condition and actions and incident reporting is improved where incident report now can be sent to multiple distribution lists. Also the very first time support for In-place eDiscovery and In-place Hold has been added for public folders with some limitations, great for compliance if you are relying on public folders and we are hoping that area will see further improvements.
Exchange will see great extensibility changes in future. MAPI/CDO is now longer supported. Although EWS is still supported for any application which relay on this but Microsoft is now investing heavily on REST APIs and the apps for Office extensibility model and this extensibility feature. It is not currently included with RTM version of Exchange 2016 but will be later release of Exchange.

[bws_google_captcha]