Create an IP-less DAG (No Administrative Access Point)

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.

Any downsides?

Couple gotchas.

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.

Lab Setup

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.

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.

Click Save.

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 Savebutton. 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.

Reader Interactions

Comments

I am kind of new to Exchange. I have Deployed Exchange 2016 CU4 on Windows 2016 Std in a LAB environment. I have configured IP-Less DAG. Now my question is, how do the clients access Exchange on Outlook or OWA. What will be the URL to access it? I have following:

Ex01 – IP 192.168.0.1 Ex02 – IP 192.168.0.2 Wintess server – IP 192.168.0.10 Do I need to have some DNS entry like 192.168.0.5 -> mail.exch.com If yes, than where will this IP point to?

Not when you create the DAG itself, but when you add a member (server) to the DAG it is installing Windows Clustering Services behind the scenes as well as making various other configuration changes and service restarts. I would plan for downtime on this one.

Hey Tom. Great question. You would want some form of load balancing behind your firewall for port 25 mail flow. For example a Kemp Load Balancer or IIS ARR. Your load balancer would have a Virtual IP (VIP). You would NAT port 25 on your firewall to that VIP. The load balancer would then distribute mail flow evenly between the servers. The DAG itself is not involved with the transport of mail.

We have 2 MBX and 2 CAS servers( second CAS server is virtual server). I have done all the things that were shown here, except creating CNO, we are using second CAS server as FWS. But our witness directory is empty there is nothing, no files and etc. Today i did some tests, i turned off my mailbox server which contain active database copies and my Outlook lost connection till i have turned on my mailbox server again. So i hope you can help me to resolve the issue. Thank you.

Something is definitely amiss. That directory should not be empty. What cumulative update are all Exchange servers on? Any errors when you created the DAG or added members to it? What is the underlying OS as well? Needs to be 2012 R2 to support IP-less DAGs.

All Exchange Servers is 2013 SP1 CU4 (Version 15.0 (Build 847.32)) and OS versions is 2012R2. There was an error when i tried add mailbox servers to DAG – “Some or all Identity references could not be translated”. I have read some articles about that error and it says there is nothing that i need worry about and i just ignored and added mailboxes.