Thoughtsofanidlemind's Blog

Most Exchange administrators, even those who don’t have much hands-on experience with Exchange 2010, are now aware that the Database Availability Group (DAG) feature is built on Windows 2008 failover clusters. Exchange 2010 does an excellent job of hiding the complexities of Windows clusters and in normal operation you aren’t aware that the DAG operates on top of a cluster. The clusters created by Exchange to be used for DAGs must be dedicated to the DAGs and not used for other purposes. This is logical because there’s a high potential that you might make a mistake that affects Exchange when you configure the cluster for another application. You don’t know what black magic is invoked by Exchange when it runs the New-DatabaseAvailabilityGroup cmdlet to create a cluster or the Set-DatabaseAvailabilityGroup cmdlet to amend the properties of a cluster.

Wrapping the DAG around Windows failover clusters makes a lot of sense. It avoids the need to create yet another mechanism to monitor and execute failovers when problems arise. It also allows Exchange to select the parts of failover clustering required to make the DAG effective while ignoring others and benefit from the ongoing investment made by the Windows development team to improve their cluster technology.

The only downside is that Exchange 2010 has to accept any limitations that originate through the use of failover clustering. The most obvious limitation is that you can only include a maximum of sixteen mailbox servers in a DAG (because that’s the limit set for failover clusters). Naming the Computer Name Object (CNO) used for the cluster is probably the other most common limitation that administrators will encounter.

Before we discuss naming schemes for the CNO, it’s good to review the material contained in the article Microsoft clustering technology in Windows Server 2008 to understand the use of the CNO. Here is the important piece:

In Windows Server 2008 Failover Clusters, the cluster service no longer runs in the context of a domain user account. Instead, the cluster service runs in the context of a local system account that has restricted rights to the cluster node. By default, Kerberos authentication is used. If the application does not support Kerberos authentication, NTLM authentication is used.

During the installation of the Failover Cluster feature, a domain user account is only required for the following tasks:

• When you run the Failover Cluster Validation process.
• When you create the cluster.

To complete each of these tasks, you must have the following access and rights:

• Local administrator access to each node in the cluster
• Rights to create computer objects in the domain

After a cluster is created, the domain user account is no longer required for the cluster to function appropriately. However, the domain user account is required to administer the cluster. To administer the cluster, this domain user account must be a member of the Local Administrators group on each cluster node. During the Create Cluster process, a computer object is created in Active Directory Domain Services (AD DS). The default location of this computer object is the Computers container.

The computer object that represents the name of the cluster becomes the new security context for this cluster. This computer object is known as the Cluster Name Object (CNO). The CNO is used for all communications with the cluster. By default, all communications use Kerberos authentication. However, the communications can also use NTLM authentication if it is necessary.

Note Computer accounts that correspond to the cluster Network Name resources can be pre-staged in AD DS. The computer accounts can be pre-staged in containers other than the Computers container. If you want to set a pre-staged computer account to be the CNO, you must disable this computer account before you create the cluster. If you do not disable this computer account, the Create Cluster process will fail.

The CNO creates all other Network Name resources that are created in a Failover Cluster as part of a Client Access Point (CAP). These Network Name resources are known as Virtual Computer Objects (VCOs). The CNO Access Control List (ACL) information is added to each VCO that is created in AD DS. Additionally, the CNO is responsible for synchronizing the domain password for each VCO it created. The CNO synchronizes the domain password every 7 days.

Now that we know the function of the CNO for the cluster, we can consider its impact on the DAG. The first thing to realize is that a newly created DAG is just an empty container that remains inert and unused until you add some mailbox servers to the DAG and then (more importantly) create some mailbox database copies through the seeding process.

There’s no practical limit on the number of DAGs that can exist inside an Exchange organization and you can create DAGs well in advance of their actual deployment. I wouldn’t go and create a set of DAGs without first sketching out on paper some salient facts about how the DAGs might be used in production. For example, you might consider the following questions to provide a guide to the DAGs that you want to create:

• The purpose of each DAG
• What mailbox servers will join each DAG and the hardware configuration that each server will use (CPU, memory, disks, NICs, etc.)
• What mailbox databases will be in each DAG and how many copies of each database will exist. Also, what is the optimum distribution of the active and passive databases within the DAG
• Who will be responsible for the administration of the DAG
• What kind of resilience  against potential problems will be factored into each DAG design
• The network configuration that will underpin each DAG
• When each DAG will be placed into production

Capturing data like this on paper encourages the development of the first pass of a solid DAG design for the organization. It also provides you with the data that you’ll need to bring the design to the next level by using tools such as the Microsoft Exchange 2010 mailbox server role requirements calculator. Hardware vendors will likely have their own tools that you can use to fine-tune server and storage designs.

Each DAG has its own cluster and trading technology, therefore its own CNO in Active Directory. The name of the DAG is also the name of the CNO in Active Directory. The question therefore is how to name the DAG/CNO. I must admit that I like simplicity and therefore use names such as “DAG1”, “DAG2”, and so on whenever possible. Users never see DAG names so the real issue is what names make sense to administrators. In some circumstances it might make sense to include the names of the part of the company that uses the databases in the DAG so you’d have names like “DAG-FINANCE” and “DAG-TRADING”. This is fine as long as you pick names that aren’t likely to change due to organizational disruption and upheaval (using more granular names such as “DAG-DEPARTMENT12” is not recommended). You could also use country or regional names to identify the DAG, an approach often taken by companies who organize IT management on a geographical basis. Names such as “DAG-DUBLIN” and “DAG-NYC” are just fine because Dublin and NYC are locations that are unlikely to vanish anytime soon. Including a more granular location name might be problematic if the company closes a location. In any case, you have up to 15 characters to create a name that must be unique within the Active Directory forest. Given that most Exchange organizations will have less than ten DAGs, it’s reasonable to assume that creating ten logically well-named DAGs shouldn’t be a huge burden!

Exchange 2010 will protect you against making mistakes with DAG naming. For example, if you use EMC and attempt to create a DAG with a name that’s too long, you won’t be able to type past 15 characters as EMC will stubbornly refuse to allow you to type in the 16th character:

Much the same protection is offered if you attempt to input an invalid character. Remember, the DAG name is the same as the CNO name and Windows doesn’t allow you to put anything but “normal” characters in a computer name.

Of course, you could try and get around the limitations imposed by EMC and attempt to create the new DAG with the New-DatabaseAvailabilityGroup cmdlet. The screen below shows what happens if you attempt to use too long a name or one that contains an invalid character.

The interesting thing here is that EMS also generates a log file. The reason is that EMS has actually attempted to run the cmdlet whereas EMC never got to that point as the safeguards built into the New Database Availability Group wizard UI stopped the creation attempt beforehand. If we investigate the log file in the DAG Tasks folder under ExchangeSetupLogs, we can see the following:

new-databaseavailabiltygroup started on machine EXSERVER1.
[2011-01-04T10:38:05] new-dag started
[2011-01-04T10:38:05] commandline: $scriptCmd = {& $wrappedCmd @PSBoundParameters }
[2011-01-04T10:38:05] Option 'Name' = ''.
[2011-01-04T10:38:05] Option 'WitnessServer' = ''.
[2011-01-04T10:38:05] Option 'WitnessDirectory' = ''.
[2011-01-04T10:38:05] Option 'WhatIf' = ''.
[2011-01-04T10:38:05] The operation wasn't successful because an error was encountered. You may find more details in log file "C:\ExchangeSetupLogs\DagTasks\dagtask_2011-01-04_10-38-05.338_new-databaseavailabiltygroup.log".
[2011-01-04T10:38:05] WriteError! Exception = Microsoft.Exchange.Management.Tasks.DagTaskDagNameMustBeComputerNameExceptionM1:
The name of a database availability group must be a valid, unique computer name. The specified name ('DAG-NameWayTooLongForE14') does not meet these requirements.

Hopefully this helps in your planning for the deployment of Exchange 2010… More details about the planning and operation of Database Availability Groups can be found in chapter 8 of Microsoft Exchange Server 2010 Inside Out, also available at Amazon.co.uk. The book is also available in a Kindle edition. Other e-book formats for the book are available from the O’Reilly web site.

Cheers,
Tony