Microsoft Exchange Server and DAG

Microsoft Exchange Server 2019 is Microsoft’s email, calendaring, contact, scheduling and collaboration platform. It is deployed on the Windows Server operating system (OS) for business use. Microsoft designed Exchange Server to give users access to the messaging platform from mobile devices, desktops and web-based systems. Telephony capabilities in Exchange Server support voice messages.

Exchange users collaborate through calendar and document sharing. Storage and security features in the platform let organizations archive content, perform searches and execute compliance tasks.

Exchange Server has evolved over time, and it is now a foundational component of Office 365 as a software as a service (SaaS) offering in the Microsoft cloud with Microsoft acting as the service provider.

How does Exchange Server work?

Exchange Server is an enterprise-class collaboration product that primarily focuses on sending, receiving and storing email messages. In addition to managing messaging traffic, Exchange Server provides several other collaboration features, like calendaring, and tight integration with other Microsoft Office applications.

Exchange Server is known for its high availability (HA) features that ensure continued service in different outage scenarios. This includes design paths that can ensure service during single-server failures or data center outages.

Exchange Server 2019 features

The 2019 release provides significantly faster and more reliable failover between servers. It was designed to improve overall performance and take advantage of the latest storage hardware, including larger disks and solid-state drives (SSDs).

Additional features in Exchange server 2019 include the following:

  • provides support for up to 256 GB of memory and 48 CPU cores;
  • enables installations on Windows Server Core;
  • enables external access to Exchange admin center (EAC) and the Exchange Management Shell to be blocked natively;
  • employs dynamic memory cache allocation to optimize memory usage for active databases;
  • prevents attendees from forwarding meeting invitations;
  • provides end users with additional Out of Office options;
  • enables administrators to cancel meetings that were organized by a user who has left the company;
  • enables administrators to assign delegate permissions; and
  • enables email addresses that contain non-English characters to be routed and delivered natively.

Along with these additional features in Exchange 2019, the Unified Messaging (UM) role and all associated functionality have been removed from Exchange 2019. A Sept. 16, 2019, blog on the Exchange Team site indicated Microsoft would push the extended support of Exchange Server 2010 from Jan. 14, 2020, to Oct. 13, 2020, to give Exchange Server 2010 customers more time to complete their migrations.

Administrators who run Exchange Server 2010 workloads on Windows Server 2008 will need to make adjustments due to the Jan. 14, 2020, end of life for that server OS.

Exchange Server 2019 requirements

The following requirements must be met to install Exchange 2019:

  • Exchange 2019 can be installed in Active Directory (AD) forests with existing Exchange 2016 and/or 2013 servers. No earlier versions of Exchange may be installed in the same forest as Exchange 2019.
  • All domain controllers (DCs) in the AD forest must be running Windows Server 2019 Standard or Datacenter, Windows Server 2016 Standard or Datacenter, or Windows Server 2012 R2 Standard or Datacenter.
  • The AD forest function level must be Windows Server 2012 R2 or higher.
  • The server hosting Exchange 2019 must use a 64-bit processor.
  • The server hosting Exchange 2019 should have between 128 and 256 gigabytes (GB) of random access memory (RAM).
  • New Technology File System (NTFS) is required on all disk partitions containing the system partition, Exchange binaries, diagnostic logs and transport database. Resilient File System (ReFS) may be used on partitions containing mailbox databases and transaction logs.

Exchange Server high availability

Exchange Server has several important features to maintain resilience and HA. The mailbox server components of Exchange rely on database availability groups (DAGs). Client access server components rely on load balancing.

Datacenter Activation Coordination mode

Datacenter Activation Coordination (DAC) mode is a feature of DAGs that is designed to prevent situations in which an outage causes two copies of a database to be live on two different servers. DAC mode requires manual intervention when the server hosting the database cannot reach a majority of the DAG member servers.

Microsoft best practices call for DAC mode to be activated on any DAG that has two or more members and uses continual replication. The only cases where DAC mode for a DAG is not recommended would be if the administrator was using a third-party replication tool.

When DAC is active, there is additional communication between DAG nodes at startup that use the DAC Protocol (DACP). DACP is set to 0 on startup. If the DACP bit remains at 0, AM will not attempt to start any databases on that node. The DACP bit may also be set to 1 if another DAG member has its DACP bit set to 1 or when a DAG node can contact all servers on its DAG membership list.

DAC mode is useful when a primary data center fails completely and a backup data center is activated. When power returns and servers come up before the wide area network (WAN) connection is back online, DAC mode prevents different copies of the same databases from ending up active in both data centers.

For a DAG with two nodes, DAC mode uses a comparison of the boot time of the alternate witness server and the time the DACP bit was set to 1 to determine if it can mount databases. If the DACP bit was set to 1 earlier than the boot time of the alternate witness server, the system assumes that the two servers were rebooted at the same time — possibly because of a power failure at the primary data center — and the DAG member is not allowed to mount databases. If the DACP bit was set to 1 after the boot time of the alternate witness server, the system assumes it is safe to mount databases.


A database availability group (DAG) is a high availability (HA) and data recovery feature of Exchange Server 2

DatabaseAvailabilityGroup cmdlets and split-brain conditions

Split brain is a situation where two different copies of the same database become active at the same time in different data centers. When this happens, the two different copies of the database diverge, causing the potential loss of user data when the two different copies attempt to reconcile.

In addition to preventing split-brain conditions, DAC mode enables DatabaseAvailabilityGroup cmdlets to be started, stopped and restored. These cmdlets are used to perform manual data center switchovers. When DAC mode is not active, the process of a manual data center is complex and involves both Exchange tools and a cluster manager.

Imagine a situation where an Exchange environment consists of four servers, each having a copy of the same database. Two of these servers are in data center A and two are in data center B. A network failure occurs in the link between the two data centers. Without DAC mode enabled, it would be possible for servers in each data center to think they needed to activate a copy of the database.

DAC mode prevents this split-brain scenario by requiring node majority before a database can be activated. Node majority means that most of the nodes in the cluster — or DAG in this case — need to be online and reachable for a DAG node to be able to activate a database copy. If there are an even number of nodes in the DAG, then the file share witness will also work as a voting member to determine node majority.

In the case described above with a four-node cluster and two nodes in each data center, only the Exchange servers in the data center with the file share witness would be able to activate databases. The DAG nodes in the other data center would be prevented from activating any databases until they were able to contact all servers that are listed as members of the DAG.

Third-site witness

A feature added to Exchange in the 2013 era was support for a third-site witness, which has the power to bring all resources online without administrator intervention. When each site has an independent network path to the third-site witness, the nodes at one site can maintain quorum using the witness server. The downside to using a third-site witness is that Exchange administrators need to take the necessary time to dig in and thoroughly understand their network behavior.

Load balancing

Load balancing is a way for administrators to manage what network traffic ends up being directed to each Exchange server within a network. Usually, it is desirable to manage the distribution of incoming client connections among Exchange 2016 servers for two reasons:

  1. To distribute the workload. If someone is going to go to the trouble of setting up and maintaining multiple Exchange servers, it’s a good idea to have all those Exchange servers do some work on a regular basis.
  2. To reduce the impact of a failure. When something goes wrong, it’s nice to have a redundant system to take over the workload of the failed system.

Load balancing complements DAGs. The job of a DAG is: (1) to ensure that there are multiple copies of each mailbox ready to be activated and (2) to accept client requests in case the active copy becomes unavailable. Load balancing works much the same way; its job is to make sure there are other places to send client traffic should one place become unavailable.

Load balancing can span between two or more Exchange servers in a single site, or it can span multiple sites. A Preferred Architecture (PA) Exchange deployment would include four Exchange servers distributed across two separate AD sites. Current versions of Exchange support Layer 4, Layer 7 and domain name system (DNS) round-robin load balancing.

Exchange Preferred Architecture

Microsoft Exchange Server

Exchange PA is the ideal Exchange deployment, as envisioned by the Exchange Team at Microsoft. The PA is developed with total cost of ownership (TCO), HA, resiliency, redundancy and recovery in mind. The PA is not intended to be used as a maturity model; it was designed to be used as inspiration.

Exchange Server clients

Exchange users access and interact with messages through an email client. Microsoft Outlook is the most common client. Exchange Server 2016 also supports the following:

  • Outlook 2016
  • Outlook 2013
  • Outlook 2010 Service Pack 2 (SP2)
  • Outlook for Mac for Office 365
  • Outlook for Mac 2011

Outlook is also available as a web-based application, called Outlook on the web — formerly Outlook Web App and commonly abbreviated to OWA — for users to access and interact with messages from many different web browsers. Outlook on the web lets users link and share documents stored in OneDrive for Business in an on-premises SharePoint server. This creates a simpler and more direct way for end users to save and attach files to emails.

Exchange on-premises vs. Exchange Online

The most common choice for businesses looking for a messaging solution will be between Exchange on-premises and Exchange Online.

Exchange Server pricing

Exchange Server pricing can vary widely based on how it is purchased and which version is being purchased.

Exchange on-premises is sold on a per-server basis. Additionally, a Client Access License (CAL) is required for each user accessing Exchange. Exchange Server must be installed on a server running the Windows Server OS, which also must be licensed with a per-server plus CAL model. The server must be installed in an AD forest with at least one DC.

Exchange Server itself comes in two license levels: Standard and Enterprise. Exchange CALs also come in Standard and Enterprise. Each user must have a Windows Server Standard CAL and may have an Enterprise CAL for additional functionality. Both the Standard and Enterprise CALs can be used with either server edition.

Contact Sales