If you would like to read the other parts in this article series please go to:
- Exchange 2016 upgrade tips and tricks from the field (Part 2)
- Exchange 2016 upgrade tips and tricks from the field (Part 3)
Introduction
Most of the customer engagements I have been dealing with have been scenarios where the customer currently was running Exchange 2010 with a wish to either perform an on-premises upgrade to Exchange Server 2016, upgrade to Exchange 2016 and establish an Exchange hybrid with Exchange Online, or establish an Exchange hybrid deployment and migrate all mailboxes to Exchange Online. The latter scenario has also involved deploying Exchange Server 2013 or 2016 hybrid servers because I was dealing with multiple Exchange forests that were going to have an Exchange hybrid established against the same Exchange Online tenant.
Note:
Although a good portion of the information in this article can be used for cross-forest Exchange migrations, this specific scenario is out of scope.
Let’s get going.
Follow the Exchange Preferred Architecture (PA)
The Exchange preferred architecture or simply PA is the Exchange Engineering Team at Microsoft prescriptive approach to what they believe is the optimum deployment architecture for Exchange 2013 and 2016, and one that is very similar to how the servers behind the Exchange Online workload are configured. You can read more about the Exchange PA in this excellent blog post on the MS Exchange Team blog.
So based on my experience, it can be difficult for an enterprise customer to adhere 100% to the Exchange PA. This is caused by several different things (see business requirements). An important recommendation in the Exchange PA I see many customers having a hard time adhering to is the storage design recommendation, which is based on underlying JBOD storage consisting of Enterprise SATA disks. While the idea is fantastic both seen from the technical standpoint as well as the reduction in storage costs compared to a traditional underlying SAN, I just don’t see many enterprises going down this route no matter how much I try to explain the benefits.
As the Exchange architect on the engagement, you should have a deep understanding of the Exchange PA so that you can design an ideal solution for the customer.
Utilize the Exchange Deployment Assistant
The Exchange Server Deployment Assistant is a web-based tool that asks you a few questions about your current environment and then generates a custom step-by-step checklist that will help you deploy different versions of Exchange Server for different types of scenarios.
While the Exchange Deployment Assistant is not super detailed, it is still a great tool to help you build a baseline for your Exchange upgrade runbook.
You can find the Exchange Deployment Assistant here.
Validate Exchange Storage using Jetstress
An extremely important activity when you are designing a new Exchange solution is to use Jetstress to verify the performance and stability of a disk subsystem prior to putting an Exchange 2013 or 2016 server into production. Jetstress helps verify disk performance by simulating Exchange disk Input/Output (I/O) load. Specifically, Jetstress simulates the Exchange database and log file loads produced by a specific number of users. You use Performance Monitor, Event Viewer, and ESEUTIL in conjunction with Jetstress to verify that your disk subsystem meets or exceeds the performance criteria you establish. After a successful completion of the Jetstress Disk Performance and Stress Tests in a non-production environment, you will have ensured that your Exchange disk subsystem is adequately sized (in terms of performance criteria you establish) for the user count and user profiles you have established.
This is of course true no matter if you use JBOD or a traditional SAN. As already mention, the JBOD approach is the recommended underlying storage. For details on how to validate this storage type, I recommend you read this blog post over on the PFE blog.
If you decide to use a traditional SAN storage for your new Exchange 2016 solution, you should avoid using disks that are shared with other systems.
You can download the Jetstress tool here.
Using an Exchange Deployment Active Directory Site
Okay so this one is not really a necessary activity in your upgrade plan, but a good idea I personally like a lot. You see, when dealing with a large Exchange messaging infrastructure that consists of lots of Exchange servers, and for this reason usually also requires the deployment of a lot of new Exchange 2016 based servers, it makes sense to deploy the new servers into a dedicated Exchange deployment Active Directory site in order to avoid clients, applications and services to start querying the new servers before they have been prepared with valid certificates, autodiscover URLs etc.
Yes, you may already be nul’ing out the autodiscover internal URL in order to avoid clients finding the servers on the SCP list, but this is not sufficient.
To avoid client certificate warnings, free/busy issues and the like, I recommend you use a dedicated Exchange deployment AD site.
This blog post over on the MS Exchange team blog explains things in more detail.
Go with a Simple Exchange Namespace Model
If you are a large enterprise customer, you should also have multiple datacenters and use these in order to not only have local high availability, but also resilience at the datacenter level. With Exchange 2010 the namespace model was quite complex as we needed multiple namespaces for each datacenter. With Exchange 2016, we can have as few as two namespaces in the ideal scenario.
When speaking datacenter resilience, you should try to go with a so called unbound model in order to keep the number of namespaces as low as possible. If you require sets of users to be bound to a specific datacenter, you will need to use a bound model though.
For a deep dive into Exchange 2016 namespace planning, I highly recommend you read this blog post over on the MS Exchange Team blog.
Getting Client Connectivity Right in a Coexistence Scenario
In an Exchange 2010 to Exchange 2016 upgrade scenario, it is crucial you have a good understanding of the client connectivity.
As a large enterprise customer, you may have multiple datacenters and sites with Exchange. Some may be Internet facing while others are non-Internet facing. You have to understand how clients are proxied or redirected based in the location of their mailbox and the Exchange client used.
For the details on client connectivity in an Exchange 2010 and 2016 coexistence scenario, see this blog post over on the MS Exchange Team blog.
Exchange Load Balancing
Since you are using Exchange 2010 with the organization, you should already have a load balancer in place. One of the major differences between Exchange 2010 and Exchange 2016 is that unlike Exchange 2010, which required session affinity at the load balancer layer, Exchange 2016 does not. Session affinity is still fully supported with Exchange 2016, but you should think about moving away from it once you upgrade to Exchange 2016 as it adds extra load on the load balancing solution.
If you plan to invest in a new load balancing solution, I recommend you go with one of the solutions here as these vendors have tested their respective solution with Exchange.
For the details on load balancing Exchange 2016, see this blog post over on the MS Exchange Team blog.
This concludes part 1 of this multi-part article series.
If you would like to read the other parts in this article series please go to:
