Exchange 2010’s Database Availability Group configuration allows you to build a highly available Mailbox Server environment without being an expert in clustering technologies; but did you know that DAGs install and configure Failover Clustering behind the scenes?
So while you don’t need to be an expert in Failover Clustering, or even remember to install it – you should at least know that it exists and treat it as such.
There are many videos and articles on the DAG configuration, but I wanted to point out a few common mistakes I’ve seen. The New DAG wizard doesn’t adhere to these best practices, so manual fix-up is required (If you aren’t using EMS).
Below are 4 tips:
- When you create a Windows Cluster, a computer account is created and in Active Directory! You should treat this account like you would any other server object.
This could mean lots of things, but at the least, you should move the object to the same OU as the mailbox server accounts. By default the DAG account will be placed in the “Domain\Computers” container. You wouldn’t want a weird GPO messing with your Exchange environment!
- Set a static IP. You’ll learn this real quick 🙂 if your server’s subnet doesn’t have DHCP; but if it does, you may go on for a long time not realizing you aren’t in control of the IP used for DAG communication. If you created your DAG in PowerShell (hey, I like PS too, but there’s a GUI so I use it!) you could have used the following commands:
New-DatabaseAvailabilityGroup -Name DAG1 -DatabaseAvailabilityGroupIPAddresses 10.2.3.4
If you used the wizard, the option to use a static IP is not exposed. To fix this you can either use the abovementioned command, but with “Set” instead of “New” – or you can go right into the Failover Cluster Manager MMC.
- Start, Administrative Tools, Failover Cluster Manager. Expand Cluster Core Resources (collapsed in the center by default). Expand your DAG name and double-click IP Address.
Select the Static IP Address bubble and fill out the appropriate IP address.
- Rename your DAG Networks. By default they are named generically, but you can fix this by clicking the Database Availability Groups tab under the global mailbox configuration. You can also use the Set-DatabaseAvailabilityGroupNetwork cmdlet. If you don’t know what to name them, I’d suggest simply calling the one facing the Client Access Servers “Public” and the 2nd one “Private”. Of course the name itself isn’t too important, as long as it is meaningful to you!
- Rename your Cluster Networks. This is not required, but I like a tidy shop, so I always rename the “Cluster Networks” to match the DAG network.
I hope you find these four tips useful. They are not required, but based on my experience I can say they will make your life easier. And a little disclaimer before you go: This post is not intended to educate you on creating a DAG; rather point out a few best practices often overlooked. For complete guidance see this great step-by-step guidance from MVP Henrik Walther here.
Have a happy and safe Independence Day!!
I’m going to disagree about the Dag IP Address needs to be static because it’s used for Dag communication. The IP Address isn’t used at all. The only reason why they exist is because Failover Clustering requires an IP Address for the Cluster Group. And the reason why the cluster group needs an IP Address is that if a CNO doesn’t have an active IP respond for it every 30 days (or whatever the value is configured for) the CNO gets cleaned up. What does the Dag use the CNO for? Authentication against the File Share Witness.
If you want to go crazy you can delete the IP Address resource in the cluster, and if you have an odd number of nodes, or enough nodes that the FSW never matters, the Dag will keep chugging along not noticing the lack of IP Address.
Of course doing so isn’t a good idea. I’m pretty sure Set-Dag and Restore-Dag would break in those conditions, but the actual IP Address isn’t that vital.