Beginning with Exchange 2013 SP1 Microsoft introduced the IP-less DAG as an option. In this article, we explore how to create an IP-less DAG, as well as the pros and cons of deploying one.
Note: With Exchange 2016 IP-less DAGs will become the default configuration.
Why would I want to do this?
Quite simply, its easier to set up.
With an IP-less DAG, you don’t need to pre-stage a Cluster Name Object (CNO) in Active Directory. This is especially useful for organizations that have implemented the split-permission model. You also don’t need to burn an IP address for the cluster.
Before you implement a DAG without an Administrative Access Point (AAP) you need to check compatibility with 3rd party programs. Backup software is typically the sticking point for migrating to the new DAGs. You need to make sure your 3rd party software doesn’t require an AAP.
The lack of an AAP means the cluster cannot be managed with Failover Cluster Manager either. But the Exchange Team doesn’t want you messing around in there anyway–and for good reason–they want Exchange to manage the cluster. Let Exchange do the heavy lifting for you.
Finally, there is no conversion process to take an IP-based DAG to an IP-less DAG. You will need to create a new DAG.
Choosing an OS (maybe)
While Windows Server 2008 R2 and above support Exchange 2013 DAGs, only 2012 R2 can support an IP-less DAG. If you wish to go with 2008 R2 or 2012 RTM, you will need to create an IP-based DAG instead. For that purpose, I recommend Paul Cunningham’s blog post here.
Are IP-less DAGs the only benefit of going with 2012 R2?
Actually, no. If I haven’t convinced you yet then consider these two additional benefits.
The first is that 2012 includes clustering in its Standard Edition. This can result in some serious cost savings compared to 2008 R2 Enterprise. Especially if you plan on building a 16 member DAG.
The second is 2012 introduced the concept of dynamic quorum. Dynamic quorum automatically adjusts the votes needed to maintain quorum as servers go offline. Take, for example, a traditional five node DAG. To maintain a quorum three servers must remain online.
If three of the five servers were to go offline quorum would be lost and the databases would dismount.
With a dynamic quorum, if two of the servers went offline their votes would be removed. At this point, the quorum is recalculated for the three remaining servers. To maintain quorum only two of the three remaining servers would need to be online. Should a third server go offline, that server’s vote would be removed and, the quorum would be recalculated for the two remaining servers. In many situations, a dynamic quorum can successfully navigate a ‘last man standing’ scenario where only a single server remains operational.
As servers come back online votes are assigned back and the quorum is recalculated.
In our example lab, we will have two multi-role servers. We also have a file server that will host our File Share Witness (FSW) directory. Based on the Exchange Team’s preferred architecture we will use a single network for all replication and MAPI traffic. We will leave the DAG to configure its own networking. We will have two copies of each database. Both servers hosting an active database. Our lab will look like this.
Configure the File Share Witness
Before we create the DAG we must set the appropriate permissions on the server destined to host our File Share Witness (FSW).
Note: If you plan to use a split-role Client Access server for the File Share Witness you can skip this section. The permissions are already in place. Keep in mind that in 2016 you will not be able to split the CAS role out anymore.
To configure permissions:
- From the file server click Start >> Administrative Tools >> Computer Management.
- Expand Local Users and Groups.
- Select Groups.
- Double-click the Administrators local group.
- Click Add.
- Type Exchange Trusted Subsystem and click Check Names.
- Click Ok twice.
Deploying an IP-less DAG
Now that our file share witness is ready, let us create a DAG. In Exchange Admin Center navigate to Servers >> Database Availability Groups and select the + (New) button.
On the DAG creation page specify the following criteria.
DAG name (1) – Whatever you wish to make it (we simply named ours ‘DAG’).
Witness server (2) – If you leave this blank Exchange looks for a split-role CAS server. Otherwise, enter the name of a non-Exchange server (in our example we specified our file server FQDN of ‘fs.skaro.local).
Witness directory (3) – If you do not specify a directory Exchange will create a default directory in the root of C: (in our example we went with C:\Witness).
IP address (4) – For an IP-less DAG specify 255.255.255.255.
Adding members to the DAG
Now that the DAG is created we need to add our mailbox servers. You can see from the screenshot below that the Member Servers column is currently empty. Select the DAG and click the Manage DAG membership () icon.
Click the + (Add) icon.
Select the servers you wish to add to the DAG and click the Add button. Click Ok.
Click the Save button.
It’s at this point Exchange installs the failover cluster components on each mailbox server, checks to see whether the server already belongs to a DAG and if not, adds it to the specified DAG.
Once complete click Close.
You can now see in the Member Server column our two multi-role servers are listed. We now have an IP-less DAG with two member servers and a file share witness. In our next article, we will explore adding database copies to each server. Stay tuned!
How about you? Have you implemented an IP-less DAG yet? How did it go? Any hiccups? We’d love to hear from you. Drop a comment below and let us know about your experience.