Respect the DAG!

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

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

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!!