Previous Post
While creating a YouTube video, I also decided to write this blog post. I revisited DAG configuration after a long time, thinking it would be useful when setting up a test environment for the upcoming Subscription Edition upgrade.
In Korea, DAG is often referred to as "redundancy." It is a feature in Exchange Server that provides automatic failover in case of database issues. A more detailed explanation involves multiple scenarios, but for now, I will keep it simple and focus on the basic setup.
The environment and specifications remain the same as in the previous post, with three Exchange Servers making up the DAG. The final architecture is as follows:
IPLess DAG Configuration
This time, I am using the IPLess configuration approach.
Database availability groups | Microsoft Learn
The IPLess configuration has the following characteristics:
- No IP address is assigned to the cluster/DAG, so there is no IP resource in the cluster core resource group.
- No network name is assigned to the cluster, meaning there is no network name resource in the cluster core resource group.
- The cluster/DAG name is not registered in DNS and cannot be resolved on the network.
- A Cluster Name Object (CNO) is not created in Active Directory.
- The cluster cannot be managed using Failover Cluster Manager but must be managed using Windows PowerShell, with cmdlets executed on individual cluster members.
I asked GPT to compare the traditional DAG approach with the IPLess approach, and the results are summarized in the table below:
| Active Directory Dependency | Requires CNO and AD objects | No AD objects required |
| IP Address | Requires static IP | No IP required |
| DNS Registration | Required | Not required |
| Failover Speed | Relatively slower | Relatively faster |
| Management Complexity | Requires AD and network management | Reduced management burden |
| Security Concerns | Requires AD object management and permissions | No AD objects needed |
If there are no compatibility issues with third-party solutions, IPLess DAG is recommended.
Prerequisites
When setting up a DAG, the disk structure must be identical across all servers. If the DB disk is set as drive D: on one server, all other servers must also configure their DB disks as drive D:
Step 1. Creating the Witness Directory
Before proceeding, let's understand what a Witness is.
1. What is a Witness Server?
A Witness Server is a server that provides a quorum vote to maintain the cluster quorum within a Database Availability Group (DAG). A DAG requires an odd number of votes (Quorum) to function properly, and the Witness Server helps achieve this.
DAGs operate as Windows Failover Clusters consisting of multiple Mailbox Servers, maintaining a quorum for high availability. If the number of Mailbox Servers in the DAG is even (e.g., 2, 4, 6...), an additional vote is needed, which is provided by the Witness Server.
You might wonder why a Witness is necessary when there are already three servers in the DAG. GPT provided the following explanation:
| Server Count | Total Votes (Including Witness) | Operation Status | Quorum Status |
| All 3 servers operational | 4 (3 servers + 1 Witness) | ✅ Running normally | OK (4/2 = 2 or more required) |
| 1 server fails (2 remaining) | 3 (2 servers + 1 Witness) | ✅ Running normally | OK (3/2 = 1.5 → Rounded to 2) |
| 2 servers fail (1 remaining) | 2 (1 server + 1 Witness) | ✅ Running normally | OK (2/2 = 1 or more required) |
| All servers fail (0 remaining) | 1 (Witness only) | ❌ DAG stops | Failed (1/2 = 0.5 → Less than 1 required) |
To ensure stable operation, a Witness is essential.
2. What is a Witness Directory?
A Witness Directory is a shared folder on the Witness Server used for DAG operations. It stores files that record the cluster state and helps determine quorum status during a failover.
Default Witness Folder Settings:
- A shared folder must be created on the Witness Server.
- Typically located at C:\DAGWitness.
- The Witness Server must be able to communicate with all Mailbox Servers in the DAG.
- The Exchange Trusted Subsystem group must have Read/Write permissions on the folder.
The Witness Server must be a separate system, and a Witness folder must be created on it. In my setup, I am using the Azure AD Connector server as the Witness Server (recently renamed to Entra ID Connect).
Creating the Witness Folder on the Witness Server
Right-click the folder -> Properties
Navigate to Sharing -> Share
Click Find People
Enter Exchange Trusted Subsystem -> Check Names -> OK
Set Permission Level: Read/Write -> Share
Click Done
Right-click Start Button -> Computer Management
Go to Local Users and Groups -> Groups -> Administrators
Click Add
Enter Exchange Trusted Subsystem -> Check Names -> OK
The Witness folder is now created and configured with the necessary permissions.
Step 2. Configuring the DAG
Next, let's configure the Exchange Servers into a DAG.
Open Exchange Admin Center (ECP) -> Servers -> Database Availability Groups -> Add
Specify the DAG name -> Enter Witness Server details -> Click Save
The DAG is created as shown below.
Click Manage DAG Membership
Add one Exchange Server first -> Click Save
The configuration process starts.
Add the remaining Exchange Servers using the same steps.
Step 3. Database Replication
After setting up the DAG, replicate the databases as follows:
Navigate to Databases -> Select a DB -> Click Add Database Copy
Add the Exchange Server -> Click Save
If circular logging is enabled, an error will occur. Disable circular logging before proceeding, then re-enable it later.
If an error occurs initially,
wait a moment and click Update to force replication.
Once complete, verify that the replication status is Healthy.
Check the other servers to confirm that replication is functioning correctly.
With this setup, your Exchange Server DAG is now fully configured using the IPLess approach, providing high availability and redundancy.