The Exchange 2016 Preferred Architecture

If you are reading this, there is a good chance that at some point you will be, or have been asked to build a new Exchange environment or upgrade an existing environment. Each of these processes will require you to design and build a new Exchange environment. When you start looking for information on designing and building your new environment, you will inevitably find mentions of the Exchange Preferred Architecture. The Preferred Architecture is the “best practice” design for an Exchange environment provided to us by Microsoft. The general theme of the PA is to keep the Exchange environment as simple as possible. In this post I’ll go over some key points included in the Preferred Architecture.

The Namespace is important to an Exchange environment because it is used by all your users when connecting to Exchange. An environment where this isn’t set up correctly will cause, you as the admin, many headaches that could be avoided by taking the time to correctly configure your namespace. There are two options when it comes to the Exchange namespace. The first is a bound namespace. This essentially means that each individual site has it’s own namespace used for connections and each mailbox will prefer to connect to the site of the active copy. The second approach is an unbound namespace. This means you have one name space with no preference for which site you connect to. If you happen to connect to the site where your mailbox isn’t active, the connection is proxied to the correct site. Microsoft recommends using an unbound namespace with a single name for each protocol (smtp, http, autodiscover, etc…) and load balancing the connections between sites.

Multiple sites is not a requirement for running Exchange, but it is a requirement for true high availability and redundancy. If you plan on utilizing multiple sites with Exchange, there are a few recommendations made by the PA. Each site should be it’s own AD site and  they should be connected using a redundant, low latency network. Ideally, the network would utilize multiple ISPs to ensure the highest likelihood that connectivity will remain consistent between sites.

The server build that Microsoft recommends for Exchange might seem a little different from what you would typically think of for an “enterprise service”. In the PA, Physical servers are the name of the game. Microsoft has built Office 365 using “commodity grade” physical servers, so that is what is recommended for on premises installs as well. While virtual servers environments are still supported, the preferred architecture recommends physical servers with the following specs:

  • Dual socket with 20-24 cores
  • Do not exceed 96 GB of RAM
  • Disk should be comprised of large capacity drives within the server chassis (no more SAN storage)
  • Battery backup write-cache

Taking virtualization out of the equation removes one layer of complexity. In addition, a correctly built Exchange environment should depend on the Exchange software for high availability taking one of the main perks of virtualization out of play.

The Preferred Architecture storage solution is probably different from how you’ve done things in the previously. SANs are a thing of the past in the Exchange world. It is recommended for each Exchange server to contain one Raid 1 drive pair for the OS, Exchange install, client/protocol logs, and the transport database. The rest of the storage should be JBOD using SAS drives. All disks that will contain Exchange databases should be configured with the ReFS. Each server should have one drive designated as a “hot spare” and set AutoReseed to format the drive correctly. Additionally, BitLocker is also recommended for each drive to provide an additional layer of data protection.

A correctly configured DAG is critical to a smooth functioning, highly available Exchange environment. A DAG is not required to run Exchange, but is a requirement for data resiliency.  The PA design ensures that in the event of a host failure, the DAG spreads the load across as many servers as possible to limit performance issues. There should be the same number of DAG members in each site. This allows a witness server to be used to maintain quorum. It is recommended to place the witness server in a 3rd location if possible, but if that isn’t an option place the witness server in one of the available sites and ensure the primary active manager for the DAG is located in that same site.

Having this info is all well and good, but how do you apply the information to your environment build. Microsoft provides the Exchange Server Role Calculator to help you plan your environment. You can use the calculator to plug in information about your environment and it will give you the recommended design based on the Preferred Architecture.

Here is where I start to deviate from Microsoft’s thoughts on the Preferred Architecture solution. Microsoft joked in an Ignite session that if you are unable to build Exchange using the Preferred Architecture, then you should just let them run it for you (meaning Office 365). And while that might be a great plan for Microsoft, it isn’t necessarily a great plan for everyone else. In my opinion, the PA is a fantastic starting place. It provides you with all the areas that need careful consideration while planning an environment. Microsoft has designed the PA based on information and lessons learned while running Exchange in the large environment of Office 365, so obviously they know what they are talking about and that info should be carefully considered. However, their plan doesn’t take into account your environment. Use the information at your disposal with the PA to make decisions that best fit your environment. You’ll have though about your design and you’ll likely better understand that design, after having considered the Preferred Architecture.