On the naming of DAGs


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:

EMC pauses at the 15th character of the DAG name

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.

An invalid character is entered for a new DAG 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.

Can't create bad DAG names through the shell either

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

Advertisements

About Tony Redmond ("Thoughts of an Idle Mind")

Exchange MVP, author, and rugby referee
This entry was posted in Exchange, Exchange 2010 and tagged , , , , , , . Bookmark the permalink.

9 Responses to On the naming of DAGs

  1. Rob Adams says:

    Tony, I was a student of the CA Maestro class in October. On the last day of the class you talked about your take on moving enterprise exchange into the cloud and at that time mentioned a white paper you had written on the subject. Is it possible to get a copy of that paper, we have one of our IT higher-ups pushing hard to host everything, even though they only have knowledge of sales pitches.

  2. Hi Rob,

    I gave Microsoft Press the content for the chapter “In the Cloud” that is supposed to be published as a web exclusive chapter. I can’t find it online yet so I assume that some production work is going on. I will ask the nice folks in Microsoft Press.

    TR

  3. Jackie Chen says:

    Hi Tony, thanks for sharing the Exchange knowledge here. I am working on an Exchange 2010 project recently, and I have been trying to find out how to retrieve the DAG swithover/failover history. But still no luck so far.

    I checked the Exchange ‘HighAvailabilty’ log in the mail server, there is too much information to allow to see the history clearly. Is there a way that I can get the information that simply tells me when the latest switchover/failover happened, and the reason?

    Thanks in advance!
    Jackie

  4. Naveen says:

    Hello Tony,

    In windows 2008 domain, I’m planning to change default location of computer object from system created Computer container to Manually created OU, so do i have take anything in consideration before moving CNO’s from Computer container to OU

    Will simply moving cluster objects to OU break something related cluster, does it require something from computer container.

    Thanks Naveen

    • I wouldn’t do this. You have no knowledge of what this might break if Microsoft makes an assumption about where the CNO is located during the installation of a future service pack or upgrade. And why do something like this anyway when there is no immediately obvious benefit from such a step?

      TR

      • Naveen says:

        Tony Thanks for reply, in my domain right now default location for all kinds of computer objects when they join domain is Computer Container, as best practices have been advised and we are planning to change it so when new computer joins it would be redirected to Different OU based on this http://support.microsoft.com/kb/324949

        Then i would have 2 places where computer accounts would be present i dont want manage it in 2 places.

        So i move the existing computer accounts (including CNO’s)to new location, i fear something might break since the above artical says

        Some applications require specific security principals to be located in default containers like CN=Users or CN=Computers. Verify that your applications have such dependencies before you move them out of the CN=users and CN=computes containers.

        Also i see the new OU wouldnt have restricted GPOS’s applied to it and i will make sure the CNO’s have create computer objects permissions on new OU.

        However still afraid if anything else might be take care or any other downsides for moving existing cnos from computer container to new location

      • “Best practice” refers to computer objects that you create as you deploy servers. It does not refer to objects created by applications that the application might depend on being in a “well-known location”. I would leave the DAG CNO where it is and concentrate on managing the objects that are under your 100% control rather than worrying too much about objects that are created and manipulated by an application like Exchange. You do not have to worry about GPOs as you won’t be managing DAG CNOs using Group Policies.

        All of that being said, please feel free to do what you want. And after you have a problem, be prepared to explain why you caused it…

        TR

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s