Many companies have good reasons to keep their messaging infrastructure on-premises. Exchange 2016 is currently the second latest version of Exchange Server for on-premises deployments. Common reasons to upgrade Exchange include adding new functionality, such as high availability, moving from an unreliable or insecure system, and moving to a version that Microsoft still supports.
For those wondering how much Microsoft is still investing in Exchange Server on-premises, Perry Clarke, Microsoft Corporate Vice-President, has stated, “The Exchange engineering team is hard at work developing the next version of Exchange. … Microsoft has no plans to stop delivering on-premises releases of Exchange.”
There are many best practices for those customers choosing to upgrade their existing messaging platform to Exchange 2016. Here are my top ten tips.
Often, customers want to upgrade because their current version of Exchange server is no longer supported or having reliability problems. An upgrade is the perfect time to determine which new features and capabilities your organization can take advantage of – things like site resilience and high availability, simplification and server reduction, legal hold and eDiscovery, improved collaboration, and more. Read What’s New in Exchange 2016 to learn about the new features.
Understand how you will introduce Exchange 2016 into your current environment. If you’re upgrading from Exchange 2013 you can easily add Exchange 2016 servers into your load balancing pools, but be aware that you cannot mix-and-match server versions in the same Database Availability Groups (DAGs). Exchange 2016 upgrades from Exchange 2010 will be deployed side-by-side in the current environment. This requires a Client Access cutover prior to moving any mailboxes. Upgrades from Exchange 2003 or 2007 require two-step migrations since there is no direct upgrade path to Exchange 2016 for these versions. Exchange 2003 must upgrade to Exchange 2010, and Exchange 2007 must upgrade to Exchange 2013 or 2010 before moving again to Exchange 2016.
Move the Exchange arbitration mailboxes first, before moving any production mailboxes. Mailbox moves from Exchange 2007 and later are online moves – users can continue to send and receive emails while their mailbox is being moved. At the end of the move, Outlook will instruct them to close and restart Outlook to complete the move.
If you use Public Folders, you’ll need to wait until all your users on migrated over to Exchange 2016 before migrating them, unless your Public Folders are on Exchange 2013. That’s a simple mailbox move.
If you’re using your old version of Exchange as your SMTP relay server, you’ll need to move that over to Exchange 2016, too. Hopefully, that’s just a simple DNS change and a new Receive Connector on Exchange 2016. If the servers and appliances currently relay to IP addresses, now is the time to convert them to use FQDNs.
You can decommission your legacy Exchange servers only after all mailboxes and Public Folders have been migrated or removed from those servers. (P.S ENow's Exchange Reporting solution has a multitude of Public Folder Reports that make planning easier)
The Exchange 2016 Preferred Architecture (PA) is the Exchange Engineering Team’s best practice recommendation for the optimum deployment architecture for Exchange 2016. It provides guidance and best practices for namespace, datacenter, server, and DAG design.
The PA is not the only way to deploy Exchange 2016, but it is the most studied and understood method. Keep in mind that one size does not fit all. The basic tenet of the preferred architecture is that complexity breeds failure, and you should only deviate from the PA when you have a valid business reason to do so. For example, the PA recommends a basic design of four Exchange servers in a single DAG – a pair of servers in each of two remote datacenters. Some smaller organizations may not have two datacenters, so accommodations must be made to the design.
The calculator is a very important part of every deployment. It validates the high-level design and calculates the number and configuration of Exchange servers (CPU, RAM, and storage), databases, and network replication. It designs for a “worst case” scenario to ensure that Exchange will still function adequately in the case of a single or double failure. If you’re not using the calculator, you’re just guessing the server configuration for your design.
Jetstress validates the storage design for your Exchange servers, be it direct attached storage (as per the PA) or storage array network (SAN). I always run Jetstress during production hours to ensure that a high-level Exchange workload will not negatively affect other workloads, especially on a SAN. You should always use Jetstress to test each node.
Jetstress is used to confirm that the storage subsystem is suitable for Exchange and will report them number of instruction operations per second (IOPS) it is capable of. Use this number to confirm it meets or exceeds the IOPS requirement calculated by the Exchange Server Roles Calculator. This IOPS rating is also helpful for troubleshooting if your storage performance degrades later, as it makes a good benchmark.
Load balancers are required for Exchange high availability and fault tolerance. They provide application health checks via probes for each client access protocol, failing over a protocol to another server if a health check fails.
Load balancers also act as your perimeter defense to Exchange from the Internet. Typically, SSL client connections will terminate on the load balancer and will then be re-encrypted to Exchange. This prevents Exchange from ever being exposed directly to the Internet for client access.
It’s important not to make a single load balancer a single point of failure since this is the front-end for client access. It’s best practice to cluster a pair of load balancers to provide fault tolerance.
If you’re upgrading from Exchange 2010 or later, you’ll need to plan for this. It involves moving your client access endpoints to Exchange 2016, which will proxy or redirect client access to your legacy Exchange server. This usually involves simple DNS changes. If you’re upgrading from Exchange 2013 this is optional since you have the option of adding Exchange 2016 servers to the existing load balancer pool.
Since almost all client access requires Autodiscover, you should always move your Autodiscover DNS record to the latest version of Exchange in your environment. Autodiscover is backward, but not forward, compatible. In other words, Exchange 2016 can serve Autodiscover responses for Exchange 2016 or earlier, but Exchange 2010 cannot serve Autodiscover responses for a newer mailbox version.
This cutover involves moving your inbound/outbound SMTP email to Exchange 2016. This can be done before, during or after the mailbox migrations. Most customers I work with do it sometime after the middle of the mailbox migrations.
Make sure you have created and configured your Receive Connectors on Exchange 2016, then reconfigure the SMTP gateways and/or firewall rules. You may need to update your SPF, DKIM or DMARC records accordingly.
Don’t forget about moving your SMTP relay services over to Exchange 2016. My best practice is to create two relay Receive Connectors, one for internal relay and another for external (Internet recipient) relay for better control.
Understand if you (still) need this. A number of customers use email archiving, either native in Exchange or using a third-party system, such as Evault. Consider moving external archives back into Exchange or moving Exchange archive mailboxes back into the primary mailbox. By moving these archives back into Exchange, you decrease your storage and license costs and improve your eDiscovery and retention capabilities. The Outlook slider can be used to configure how much data is stored on the local PC to reduce local storage.
Journaling is used to make a copy of every message send or received by users. Consider whether Exchange 2016 litigation hold and eDiscovery will fit those needs without increasing storage. Keep in mind that journaling is not considered in the Exchange Storage Calculator, so you’ll need to plan for this. If you do decide you need journaling inside Exchange, best practice is to put journal mailboxes in their own dedicated mailbox databases.
Users will always get the best performance and experience using the latest versions of Office. I recommend updating Office prior to the Exchange 2016 upgrade. This can be carried out while the design and planning are performed.
If your organization uses Office 365, even though you keep email on-prem, your Office 365 license may include Office 365 ProPlus. This version is super easy to deploy, and users will always be running the latest version of Office – all without having to handle patch management.
ENow can help save time and reduce risk during your migration by providing:
Through a partnership with Enow Software, EXPTA Consulting can help your business with the following: