ICT-Hotlist Topic

Back to the ICT-Hotlist...

The Exchange 2016 Preferred Architecture (Best practice)

By Johan van Soest.

Published : 2015-11-19.

Last updated : 2017-05-02.

The Preferred Architecture (PA) is the Exchange Engineering Team's best practice recommendation for what Microsoft believes is the optimum deployment architecture for Exchange 2016. The PA is divided into four areas of focus:

Namespace design
Datacenter design
Server design
DAG design

Exchange HA storage system and Backup

The best practice advises to run Exchange 2016 on DAS SAS disks using ReFS and BitLocker disk encryption for the mailbox databases using the unbound model. Now re-read and think about the implications of the previous line as we are accustomed to using Enterprise SAN's and lots of virtual machines.

DAS in a JBOD configuration can be used because fault tolerance is established in the DAG, with multiple database copies, not with fault tolerant disk arrays which make your storage cost go needlessly higher.
Enabling BitLocker on Exchange Servers using TPM 2.0 (recommended approach). A TPM can only be used in a physical server deployment as virtualized servers are not capable of using a TPM. Active Directory based Recovery passwords for BitLocker requires Windows Server 2012 R2 or later. BitLocker is used to safeguard the data on the disks in case of theft of the server and or disk drives.
Using the PA, backups are unnecessary as the PA leverages Exchange Native Data Protection. Exchange Native Data Protection relies on built-in Exchange features to protect your mailbox data, without the use of backups (although you can still use those features and make backups).
Recommended is deploying a minimum of three (non-lagged) copies of a mailbox database before eliminating traditional forms of protection for the database, such as Redundant Array of Independent Disks (RAID) or traditional VSS-based backups. Each Mailbox database has four copies, with two copies in each datacenter, which means at a minimum, the PA requires four servers. Out of these four copies, three of them are configured as highly available. The fourth copy (the copy with the highest Activation Preference number) is configured as a lagged database copy. The purpose of the lagged database copy is to provide a recovery mechanism for the rare event of system-wide, catastrophic logical corruption. It is not intended for individual mailbox recovery or mailbox item recovery.
The unbound model is a single namespace so either datacenter can service the user request in case there is a WAN failure or Disaster. Data is routed to the mailbox server using the original protocol as RPC Client access is not supported anymore.

So now it is time to study the Exchange 2016 PA in-depth and consider how this architecture can be implemented in your organization.

You may vote your opinion about this article:

Scripts and programming examples disclaimer

Unless stated otherwise, the script sources and programming examples provided are copyrighted freeware. You may modify them, as long as a reference to the original code and hyperlink to the source page is included in the modified code and documentation. However, it is not allowed to publish (copies of) scripts and programming examples on your own site, blog, vlog, or distribute them on paper or any other medium, without prior written consent.
Many of the techniques used in these scripts, including but not limited to modifying the registry or system files and settings, impose a risk of rendering the Operating System inoperable and loss of data. Make sure you have verified full backups and the associated restore software available before running any script or programming example. Use these scripts and programming examples entirely at your own risk. All liability claims against the author in relation to material or non-material losses caused by the use, misuse or non-use of the information provided, or the use of incorrect or incomplete information, are excluded. All content is subject to change and provided without obligation.