Microsoft has made an effort to facilitate the deployment and coexistence of Exchange 2016 with legacy versions...
but the new version has certain requirements around operating system and forest-functional level support. And even though Exchange 2016 is still in the works, these guidelines and requirements won't change. Here's what to keep in mind when planning an Exchange 2016 deployment.
Exchange 2016 roles. Microsoft recommends that companies deploy multirole servers in Exchange 2010 and Exchange 2013, but some IT admins separated the roles during deployment because they didn't understand how the roles' resiliency is architected. With Exchange 2016, the company ensures that all deployments will combine all functionalities of Client Access proxy components, core server protocols and mailboxes into a single role. Aside from the optional Edge Transport role, Exchange 2016 has a single mailbox role. Microsoft has confirmed that the Edge role will be available in Exchange 2016's release to manufacturing (RTM).
Even though admins only need to deploy a single role, the client doesn't connect directly to the Mailbox 2016 back-end endpoints. Connectivity will be through the Client Access services, which will run on the same box.
Topology requirements. Exchange 2016 can coexist with Exchange 2013 Cumulative Update 10 or later and Exchange 2010 Service Pack 3 Rollup Update 11 or later. The exact update versions may change as the release date for Exchange 2016 RTM gets closer, depending on any bugs or compatibility issues found while running Exchange 2016 in Office 365 and internal Microsoft dogfood environments. Existing Exchange deployments running pre-2010 versions will need to migrate to Exchange 2010 or Exchange 2013, depending on the originating version, and then upgrade to Exchange 2016.
Only Windows Server 2012 R2 and Windows 10 will support Exchange 2016. The forest and domain functional level needs to be at least Windows Server 2008 R2. This means that all existing domain controllers and global catalog servers should be upgraded to at least Windows Server 2008 R2. Exchange 2010 and Exchange 2013 only required Windows Server 2003 functional level, so this will need to be addressed before deploying Exchange 2016.
Outlook requirements. Exchange 2016 will support three major versions of Outlook, provided that the required patches are installed on the machines. The clients should be running at least Outlook 2010 SP2 (with KB2956191 and KB2965295), Outlook 2013 SP1 (with KB3020812) or Outlook 2016 to be able to connect to an Exchange 2016 mailbox.
MAPI/CDO. While Messaging Application Program Interface (MAPI) and Collaboration Data Objects (CDO) have been around for a long time, most enterprises have at least one application that leverages the technology. But Exchange 2016 doesn't support it.
App connectivity using the MAPI/CDO library will be blocked in Exchange 2016. This means that companies will need to upgrade any apps currently using this library, such as BlackBerry Enterprise Server (BES) 5.x. All apps using MAPI/CDO should start using connectivity via Exchange Web Services or RESTful APIs. Enterprises that want to keep BES must migrate the BES 5.x to a version that uses Exchange ActiveSync.
Load-balancing requirements. Similar to Exchange 2013, Exchange 2016 doesn't require session affinity at the load-balancing layer. While configuring load balancing, ensure that the load balancer and Managed Availability in Exchange have the same picture regarding the status of multiple protocols. Managed Availability runs on all Exchange 2016 boxes (and in Exchange 2013), monitors the status for a number of protocols and takes corrective measures, such as resetting an application pool or restarting the service or server, to fix an issue.
The load balancer shouldn't send connections to a server with protocol Managed Availability marks down. The Exchange team recommends using a single namespace at Layer 7 with no session affinity. This way, the load balancer can inspect the incoming connection and perform a health check for that particular protocol before sending the request to an Exchange 2016 mailbox server.
Exchange 2016 mailboxes. With Exchange 2016, it's easier to introduce the mailbox role into an existing Exchange 2013 deployment because an Exchange 2013 CAS server can "up-version proxy" the connections to an Exchange 2016 mailbox server. This gives IT admins the flexibility to deploy Exchange 2016, create database availability groups and move mailboxes without changing the existing load balancing rules set for Client Access Servers (CAS).
Admins can slowly introduce Exchange 2016 mailbox servers into the load-balancing pool and the servers can coexist with Exchange 2013 CAS. This is a huge win as admins can move the pre-pilot mailboxes without much work in the back end and start to test all the functionalities.
About the author:
Rajith Enchiparambil is a UC Architect who works on large Exchange and Office 365 projects for clients in the U.K. He specializes in Exchange, Office 365, Active Directory and a bit of Lync. He has been working in the IT industry for the last 13 years and has worked extensively with Microsoft Exchange since version 5.5. Enchiparambil has worked for consultant services such as HP, Siemens, AtoS, CapGemini and Computacenter. He regularly writes about Office 365 and Exchange in his personal blog, theucguy.net.
Admins' first glimpse at Exchange Server 2016
Experts react to Exchange 2016 features and capabilities
Will it be easier to deploy Exchange 2016?