Exchange Server is a very tolerant software product and allows for installation in different IT infrastructure environments. Some of the possible infrastructure environments are well suited for running Exchange Server, others are less good.
When planning an Exchange Server implementation, do not forget the fundamental principle for modern Exchange Server versions:
High availability of Exchange Server is implemented at the application level.
Unfortunately, this fundamental principle is ignored too often. This ignorance is in most cases encouraged by manufacturers wanting to sell their own high-availability (HA) solution. These solutions include both, HA capabilities of hypervisor platforms, and, more often, HA solutions from storage vendors.
The standardization of an IT platform cannot be ensured by declaring an unnecessary complex infrastructure as standard, but by defining a simple platform implementation as the standard.
Countless support requests to the Exchange product group have matured the Preferred Architecture (PA) over the years. The PA is nothing new in the planning space for Exchange Server. It is a result of the requirements and knowledge gained during the day-to-day operation of the highly available cloud infrastructure of Exchange Online.
Obviously, you will now argue that you do not want to run a cloud platform. However, you must remember that a modern Exchange Server version wants to run in high availability mode. The experience provided by the PA helps to ensure a proper HA implementation. Do not forget the fundamental principle for modern Exchange Server versions from 2013 onwards.
High availability of Exchange Server is implemented at the application level.
At the Microsoft Ignite Conference 2017, the Preferred Architecture was referenced in numerous breakout sessions. Personally, I was under the impression that a missionary took place. On the last day of the conference, Boris Lokhvitsky and Robert Gillies held an interesting breakout session about the optimal implementation of Exchange Server. The minimum technical requirements were discussed, as well as the optimal operating environment. The core message was that for an optimal operation of an on-premises Exchange Server implementation you should follow the Preferred Architecture. If this is not possible, you should opt for a move to Exchange Online.
The following diagram, shown in the breakout session, illustrates the different design options for messaging platform based on Exchange Server 2016.
What does this mean in detail for a successful Exchange Server implementation?
Standardized - Exchange Online provides a standardized platform for Exchange Server services as part of the Office 365 Software-as-a-Server offering. In this case, you only use the Exchange Server functions and have no direct access to the underlying server systems. The entire administration of the operating system and the patching of Exchange Server is handled by Microsoft. You can focus on the configuration of your Exchange Online organization or the hybrid setup with your remaining on-premises Exchange organization.
Structured - The structured implementation of an Exchange Server platform follows the Preferred Architecture of the Exchange Server product group or the Product Line Architecture, based on the recommendations and insights of Microsoft architects. Such an implementation, as well as the use of Exchange Online, are a solution for the optimal operation of Exchange. The main topics of the Preferred Architecture are described in detail below.
Recommended - An on-premises Exchange Server implementation that follows the Exchange Server best practices differs significantly from the Preferred Architecture, while still providing secure and stable operation. Such a deviation can be the operation on a hypervisor platform, but applying the best practices for running Exchange Server on physical systems (keyword: fixed resource allocation). The Exchange Server Best Practices Analyzer is a click-to-run application that can be accessed directly from the on-premises Exchange Admin Center. Alternatively, you can use the Exchange Analyzer Script by Paul Cunningham from the TechNet Gallery.
Supported - A supported implementation of Exchange Server differs in many ways from the Preferred Architecture, but still follows the Microsoft system requirements for a supported deployment. Such requirements are described in the Exchange Server Supportability Matrix and the Exchange 2016 storage configuration options. This type of implementation is an absolute minimum.
Kinda works - Of course, you can implement Exchange Server in a way that it works somehow. This is the last category of possible design options. This category includes, for example, single server implementations using redundant storage systems or the operation of Exchange Server with unsupported storage systems (see Exchange 2016 storage configuration options). This area also includes Exchange Server implementations on AWS or Microsoft Azure without premium storage. Your productive Exchange Server platform should not be part of this last category because otherwise, you will incur an unnecessary high operational risk.
What is the much-cited Preferred Architecture and what does it mean for a successful on-premises implementation of Exchange Server?
The Preferred Architecture by itself is not a rigid pattern. Rather, it adapts regularly to new technical conditions. Lastly, the recommendation for the maximum memory per server increased from 96GB to 192GB.
The four sections of the Preferred Architecture are described below. However, I strongly recommend that you always refer to the updated EHLO blog article and familiarize yourself with the Exchange Server 2016 architecture in detail.
The Preferred Architecture is divided into the following four areas:
Namespace Design
An Exchange Server namespace describes the DNS host names required by clients (e.g. Outlook, browser, or mobile devices) to connect to Exchange Server. The data center design utilizes two data centers (see below).
The Preferred Architecture namespace design differentiates between so-called bound and unbound namespaces for Exchange servers located in two data centers.
For a bound namespace, each data center has a unique name for accessing Exchange Server client access services. This is required for a client to connect directly to the data center where the active copy of the mailbox database is mounted.
For an unbound namespace, the data centers do not have their own names for accessing Exchange Server client access services. A load balancer routes client connections to any of the data centers. The load balancers do not use session affinity, which allows for a better utilization of the Exchange servers. An exception in this model are the Office Online Servers (OSS), which always require a bound namespace.
The unbound namespace is the preferred namespace design option.
The following example for a Preferred Architecture namespace design requires four names:
Data Center Design
A highly available and fail-safe architecture for running Exchange Server requires at least two data centers. These two data centers can be either two full-fledged and stand-alone data centers or two local server room in separate fire sections in the same building. This post is not about the physical planning of data centers.
However, in regards to two data centers and server locations an important requirement is the optimal operation of Active Directory in the Preferred Architecture. It is technically supported to stretch an Active Directory site across two physical locations. The Preferred Architecture recommends configuring each physical location as separate Active Directory site. This provides a fail-safe operation of email transport with Shadow Redundancy and Safety Net and follows the Active Directory design recommendation to place network segments with a latency of 10ms or more in separate Active Directory sites.
Server Design
The Preferred Architecture recommends that all server hosting an Exchange Server mailbox role are physical servers. The physical servers are sized to maximum of 80% utilization in a greatest possible failure scenario. Virtualization introduces an unnecessary complexity to the infrastructure providing no real benefit for running Exchange Server.
Other technical specifications, such as form factor, memory, or storage, are described in detail in the EHLO blog post about the Preferred Architecture. From an operating standpoint ReFS, BitLocker, and DAG AutoReseed provide additional functionality for security and faulty file system situations.
DAG Design
A database availability group (DAG) groups up to 16 Exchange servers running the same version of Exchange and provides high availability and resiliency for server or mailbox database failures. The concept of a DAG has been introduced to Exchange Server in version 2010.
All active database copies are distributed evenly across all DAG member servers, to ensure the optimal use of the system resources in an unbound namespace design. More member servers in a DAG ensure better redundancy and resource utilization. The Preferred Architecture recommend to start with eight DAG member servers across two data centers.
Witness Server
The Witness server is a critical component of a DAG and ensures the correct behavior of the DAG in case of a failover if a data canter failure occurs. Ideally, the Witness server is placed in a third Active Directory site. If a third location is not available, you can also operate the Witness server in Microsoft Azure.
By following the Preferred Architecture (blue circle) of the best practices recommendation (purple circle), you can ensure secure operation of the messaging platform in your organization without taking unnecessary technical risks. Beyond the use of Exchange Online, these two design options represent the optimum for a reliable operation of Exchange Server. The more you deviate from the Preferred Architecture for Exchange Server, the more the operating risk increases.
If you follow the full-bodied product promise from third-party vendors for storage solutions or other fascinating solutions to Exchange Server high availability, then you are going to adopt an individual “kinda works” implementation. If a fault occurs in such an implementation, such as data loss, the problem is not with the Exchange Server product.
The absolute minimum is an Exchange Server implementation that follows the Exchange Server Supportability Matrix and the Exchange 2016 storage configuration options.
Are you ready to see the entire landscape of your Microsoft Exchange environment, eliminate costly outages, and provide crucial analytics for key stakeholders?