Introduction
In this post, I’ll demonstrate how to set up a simple Exchange 2016 Database Availability Group with two servers on the same subnet. We’ll go through some background information then set up a DAG and configure our networking.
To read other parts in this series go to:
Exchange 2016 DAG Basics
An Exchange DAG is the mailbox role high availability. Setting up a DAG therefore only provides high availability for mailbox databases and public folder mailboxes stored in these databases. If you want CAS high availability then you’ll need to use DNS round robin or an external load balancer but we’ll discuss CAS load balancing in another post.
Points to note:
- Exchange DAGs don’t require shared storage (mailbox databases are stored on the local disks on the server and logs are shipped to other servers)
- All mailbox servers must be in the same AD domain
- You create database copies but are limited to 16 copies for each database
- You can’t create a database copy on a server that already has an active or passive copy of that database
- The mailbox servers cannot be domain controllers – this is not supported
- When a DAG is set up, a Windows Failover Cluster is set up. You cannot use this cluster for any other servies – this is not supported.
- Datacenter activation coordination (DAC) mode prevents a split brain scenario where the same database is active in both datacenters and you then get dirvergence of data where changes are made to both databases but not replicated across. DAC is not enabled by default but should be enabled for all DAGs. We’ll enable this on our DAG.
- DAGs only provide high availability for the mailbox role (the mailbox databases). It doesn’t provide high availability for the client access services (OWA, Outlook, ActiveSync etc). You will need to set up load balancing for the client access services using either DNS round robin or a hardware load balancer. For information on how to configure DNS round robin and the advantages/disadvantages of using this over a hardware load balancer, see here.
Networking requirements
- Use at least 1Gb connections for the DAG members but 10Gb is preferable
- You can configure a DAG with a single network which will be used for MAPI and REPLICATION or you can set up two separate networks – one for MAPI and one for REPLICATION. The latter is preferred for performance and high availability although it adds some complexity.
- If you’re using separate MAPI and REPLICATION networks, a MAPI network failure will cause a server failover. If the REPLICATION network fails then the MAPI network will be used for replication even if the RecplicationEnabled property on the network is set to False. Manual fail back to the REPLICATION network will be necessary if it is restored. To fail back, suspend and resume the mailbox database copy. The other option is to restart the Microsoft Exchange Replication service but this causes a brief outage.
- Each DAG member requires the same number of networks and network adapters
- Additional REPLICATION networks can be added and you can configure teaming on the REPLICATION network adapters although this does add complexity
- Each DAG member must only have one MAPI network which needs to have access to other Exchange servers, DNS and AD
- The MAPI network adapter for each server must be able to communicate with each other server’s MAPI network and should be the only network adapter configured with a default gateway
- The REPLICATION network adapter for each server must be able to communicate with each other server’s REPLICATION network
- The REPLICATION network should be isolated from other REPLICATION networks (if you’re using multiple REPLICATION networks) and also isolated from the MAPI network
- Roundtrip latency must be lower than 500ms however you must also look at the effect of this latency on other services e.g. CAS services
- Automatic Private IP Addressing (APIPA) for DAG members is not supported
Quorum and witness server requirements
You must always have an odd number of voters in a cluster. If you have an even number of mailbox servers in the DAG, the DAG will use a node and file share majority quorum model where it will use a file share witness which is created on a witness server during the DAG setup. If you have an odd number of mailbox servers in the DAG then the DAG will use the node majoirty quorum model and the file share witness will not be used.
The witness server can be any server in the domain running Server 2003 or later but not a DAG member because you’ll lose two votes if that member goes down and ideally not a domain controller as this means that the Exchange Trusted Subsystem has more permissions than it requires which is not a best practice.
The DAG will create a file share on the witness server and will use this as a voter in case you have an even number of mailbox servers.
Lab environment
As we start the demonstration, I’ll give you a quick run through the servers I have in this lab. I have two Exchange 2016 servers in the litwareinc.com domain which has two domain controllers and a file server as below:
All servers are running Server 2012 R2. We’ll set up a DAG using these two Exchange servers.
Set up MAPI and REPLICATION networks
We’ll use the current network (10.2.0.0/16) as the MAPI network. We then need to add an additional network adapter on each Exchange server to be used for the REPLICATION network – it’s a good idea to name the network adapters to avoid confusion.
Set up a REPLICATION network on an isolated subnet. It should not be able to route to the MAPI network or other networks. In this case, I’m using 172.16.0.0/16.
The REPLICATION network should not have a default gateway or any DNS servers configured. You should now have networking that looks something like this:
Just to confirm, your IPCONFIG output for should look like this (this is for LITEX02):
The next step is to disable the network features that are not required. For the MAPI network adapters, we don’t need to change any of the defaults. You should have the below enabled (yes, IPv6 should be enabled!)
For the REPLICATION network adapters, disable the below features:
- Client for Microsoft Networks
- File and Printer Sharing for Microsoft Networks
Your replication network should now look like this:
On the REPLICATION network adapters, ensure that they are configured not to register their addresses in DNS. To do this, double click on the network adapter, double click on Internet Protocol Version 4 (TCP/IPv4):
Then click on advanced then the DNS tab and untick “Register this connection’s addresses in DNS” as below then press OK on all windows.
That’s it for networking. Next up is the witness server configuration.
Configure the witness server
The witness server shouldn’t be a domain controller or a DAG member. In this case, we’re left with only our file server so we’ll use that. When we create the DAG, Exchange will create a witness directory and share on the witness server. To do this, it requires that the “Exchange Trusted Subsystem” AD group is a local administrator on the witness server. If you’re interested in the membership of the group, it includes all the Exchange servers:
Add the “Exchange Trusted Subsystem” group as a local administrator on the witness server:
Create an Exchange 2016 Database Availability Group
All the preparation is now done and we’re good to go ahead and create our DAG. We can use either the Exchange Admin Center (EAC) or PowerShell to do this. EAC and PowerShell instructions are below:
Create an Exchange 2016 DAG using the Exchange Admin Center
Log into the Exchange Admin Center using an account that’s a member of the Organization Management AD group or assigned the Organization Management or Database Availability Groups roles in Exchange:
Click on Servers then click on Database Availability Groups:
Click the + icon to create a new Database Availability Group then assign a name, witness server and witness directory for your DAG. I’m using the settings below:
- DAG Name: DAG01
- Witness Server: LITFS01
- Witness Directory: C:DAG01-witness
As we’re using Server 2012 R2, we can set up an IP-less DAG. These are recommended and simpler to manage and set up but not supported unless you’re running Server 2012 R2 or later. Note that you cannot manage an IP-lesscluster using the failover cluster management console – you need to use PowerShell. We therefore don’t need to add an IP address as per the screenshot below. Once you’re entered the details, click on Save.
We now have a DAG set up:
The DAG has no members – it’s just an AD object at the moment. To add a server to the DAG, highlight the DAG in the screenshot above and click on the 
icon.
Click on the + icon to add servers:
Add the Exchange servers you want to add to the DAG:
Then press OK. You’ll be presented with the window below. Click Save.
Exchange now prepares the servers and then adds them to the DAG. You’ll notice that the Windows Failover Clustering feature is installed as part of this process:
Our DAG is now created:
Click close and we can now see that our DAG has both LITEX01 and LITEX02 as members:
Create an Exchange 2016 DAG using PowerShell
Hopefully you’re now starting to use PowerShell more. If not, maybe the fact that we can create a DAG in three lines of PowerShell may sway you a bit more.
First, create new DAG with the settings below:
- DAG Name: DAG01
- Witness Server: LITFS01
- Witness Directory: C:DAG01-witness
New-DatabaseAvailabilityGroup -Name DAG01 -DatabaseAvailabilityGroupIPAddresses ([System.Net.IPAddress]::None) -WitnessServer LITFS01 -WitnessDirectory C:DAG01-witness
Next up, we will add LITEX01 to the DAG:
Add-DatabaseAvailabilityGroupServer -Identity DAG01 -MailboxServer LITEX01
Then we’ll add LITEX02 to the DAG:
Add-DatabaseAvailabilityGroupServer -Identity DAG01 -MailboxServer LITEX02
Configure DAG networks
We need to set our DAG so we can configure our networks manually as this is not possible by default. We then need to disable replication for our MAPI network.
Configure DAG networks using the EAC
Double click on our newly created DAG and tick the option “Configure database availability group networks manually” as below then click Save:
By default, all networks are enabled for REPLICATION. As we have a dedicated REPLICATION network, we need to make a change to the defaults.
If we highlight the DAG, we can confirm that the DAG has identified two networks as we can see the MapiDagNetwork and ReplicationDagNetwork01 and that both have replication enabled on the right hand side pane under DAG Network:
To disable replication for the MAPI network, click on Disable Replication under MapiDagNetwork:
Press OK when prompted.
Configure DAG networks using PowerShell
Enable manual DAG network configuration:
Set-DatabaseAvailabilityGroup DAG01 -ManualDagNetworkConfiguration:$true
Disable replication on the MAPI network:
Set-DatabaseAvailabilityGroupNetwork -Identity DAG01MapiDagNetwork -ReplicationEnabled:$false
Confirm that only the REPLICATION network is configured for replication by running this command:
Get-DatabaseAvailabilityGroupNetwork
Enable Datacenter Activation Coordination Mode
As we briefly discussed above, this prevents a split-brain scenario and although not enabled by default, it’s recommended. Unfortunately there’s no option to do this using the EAC so we’ll need to use PowerShell:
Set-DatabaseAvailabilityGroup DAG01 -DatacenterActivationMode DagOnly
Confirm the DAG was set up correctly
We’ll go through a few checks to ensure that we have indeed set up our DAG correctly.
Confirm the cluster exists:
Get-Cluster
We can see the DAG01 cluster is created.
Confirm that all nodes are up in the cluster:
Get-Cluster | Get-ClusterNode
Here we see that both servers are up in the cluster.
Confirm that the DAG was created successfully and that both servers are operational:
Get-DatabaseAvailabilityGroup –Status
And there you go. One DAG.
Conclusion
In this post we have gone through the steps you need to go through to set up an Exchange 2016 DAG. In the next post, I’ll demonstrate how to set up mailbox database copies so that our databases are highly available. Click here to go to part 2.