Exchange 2013 DAGs, Windows 2012, and the CNO

All DAGs are built on top of Windows Failover Clusters. All Windows Failover Clusters use a Cluster Name Object (CNO), an Active Directory computer object that essentially gives the cluster (and therefore the DAG) its identity. The CNO is also used for all communications within the cluster. You don’t have to know anything about the CNO to work with the DAG as this object is used for internal purposes within the cluster. However, you do have to create the CNO manually before you add any mailbox servers to the DAG if the servers run Windows Server 2012.

This isn’t the case when you work with Windows Server 2008 R2 SP1 as Exchange is able to create the CNO when it builds out the DAG – or when you use Exchange 2010 to create a DAG on Windows 2008 SP2 or Windows 2008 R2. However, Windows 2012 made a change that restricts the creation of computer accounts that had an unfortunate knock-on effect of stopping Exchange 2013 being able to create the CNO, hence the need to pre-stage a CNO before you proceed to build the DAG. Quite a few people who are playing with Exchange 2013 (sorry, the professional words that I should use are “testing”, “assessing”, or “validating”) have run into the problem and discovered that things don’t go quite as smoothly as expected when they attempt to create an Exchange 2013 DAG.

Exchange Server 2013 DAG setup

The steps to pre-stage a CNO for a DAG are straightforward. Here’s what you need to do:

1. Use the Active Directory Users and Computers console to create a new computer object in the desired organizational unit (OU). Often this will be the default “Computers” OU that is present in every Active Directory, but there is nothing to prevent you using a different OU, such as a new OU called “Exchange DAGs”. The Microsoft article "Redirecting the users and computers containers in Active Directory domains" provides guidance on how to redirect the default creation of computer accounts in Active Directory.

2. The name assigned to the CNO will be the name of the DAG. Do not use a name such as “Exchange” or “Email” as the potential exists that these names might be confused with an application now or in the future. Select a name that clearly indicates the purpose of the object such as “DAG1” or “DAG-DC1.”

3. After you create the new computer object, right click on it and disable the account. The account must be disabled as otherwise Windows Failover Clustering will not be able to use it as a CNO.

4. You now need to assign the necessary permissions to the new computer object. First, make sure that Advanced Features are enabled from the View menu in the Active Directory Users and Computers console. Then, select the computer option and click Properties, then click Security to reveal the current security settings for the object.

5. Exchange 2013 uses its membership of the Exchange Trusted Subsystem security group to manage the DAG. Therefore, the Exchange Trusted Subsystem must be added to the list of objects that have Full Control access. Click on Add, enter “Exchange Trusted Subsystem” as the object name to which permissions are to be assigned and then select Full Control in the Allow column. Click OK to complete the assignment.

6. Alternatively, you can add the name of the first member node (mailbox server) that will join the DAG. To do this, click on Add, select “Computers” as the object type, and input the name of the member node. Click OK and then select the name of the computer account for the node (it should be the same name). The member node also needs Full Control permission, so click on this value in the Allow column and click on OK to complete the assignment.

After the permissions have been assigned, you will be able to create the DAG through the Exchange Administration Center (EAC) or by running the New-DatabaseAvailabilityGroup cmdlet. You do not have to assign Full Control access to the other member nodes that are subsequently added to the DAG after the first member node is in place.

Happy DAG’ing!

Follow Tony @12Knocksinna

Discuss this Blog Entry 2

on Dec 3, 2012
In my experience Step 6 was not necessary. I just removed first mailbox server from permissions as it wasn't successful when running Add-DatabasseAvailabilityGroupServer cmdlet. Performing step 5 and then running Add-DatabasseAvailabilityGroupServer worked fine. Also, New-DatabaseAvailabilityGroup was successful without pre-staging, it was only when I tried to add first member it failed since the CNO had incorrect permissions. I am not sure if this is a regression as Exchange 2010 process, or deploying DAG when Exchange 2013 mailbox servers on 2008 R2 SP1 works as expected. Forcing pre-staging on Windows Server 2012 is counter-intuitive. I hope Microsoft provides some explanation or fixes the issue going forward.
on Dec 19, 2012
Thanks for the comment. You're right that Step 6 is optional, which is why I have "alternatively" there... but in any case, the facts are that you have to prestage the CNO in a particular manner to make everything work for a DAG in Exchange 2013 on Windows 2012. Deploying the DAG on Windows 2008 R2 SP1 servers doesn't have the same problem because it's due to tighter controls on computer account creation that only exists in Windows 2012.

Please or Register to post comments.

What's Tony Redmond's Exchange Unwashed Blog?

On-premises and cloud-based Microsoft Exchange Server and all the associated technology that runs alongside Microsoft's enterprise messaging server.

Contributors

Tony Redmond

Tony Redmond is a senior contributing editor for Windows IT Pro and the author of Microsoft Exchange Server 2010 Inside Out (Microsoft Press) and Microsoft Exchange Server 2013 Inside Out: Mailbox...
Blog Archive

Sponsored Introduction Continue on to (or wait seconds) ×