Do you virtualize all of your domain controllers?

This is a fine question and one that generates a bit of good natured discussion. Several have answered immediately with a resounding, “Yes!” and though no one that I have talked to has come out and said “No!” with the same vigor and intensity as those in the “Yes!” crowd, you can see the struggle within, how hard it is to say “No” even sheepishly to this question no matter how strongly they may feel.

When dealing with virtual server infrastructure, I spend the majority of my time working with VMware but also work with Citrix XenServer a decent amount. I worked with that Microsoft hypervisor thing once, will only do so again if forced to, and even then, I may decide to switch to another line of work altogether to avoid it. I wouldn’t virtualize anything on the MS Hypervisor, much less my domain controllers!

But we’re talking about VMware here, so what do you do? It’s tough to say “No” because the product is so dependable and reliable, it’s almost of if you’re insulting VMware and who wants to do that? The good news is that neither “Yes” or “No” is the right answer 100% of the time. You can certainly virtualize all your domain controllers and you can certainly choose not to as both are valid options.

I believe the biggest concern with virtual domain controllers has to do with time, and keeping it synchronized. As we all know, keeping time synchronized in an Active Directory domain is of vital importance.

In a virtual environment, clock drift can be significant in a relatively short time. If a domain controller and a “chatty” VM are hosted on the same ESX server, it is possible that all CPU cycles will go toward this chatty VM. In that case, the domain controller will queue up its “timer ticks” and time drift will occur for this VM, this is very bad for DCs. In test performed by VMware, a DC drifted by 1700 seconds (28minutes) when hosted on ESX server with resource intensive VMs.

Typically there are two options when dealing with VM time synchronization and the method chosen determines how many DCs can be virtualized. It’s important to pick one option or the other when virtualizing DCs, do not use both! If the methods are mixed, the likelihood of time synchronization issues only increases, especially if DCs are vMotioned among ESX hosts.

1. Use the Windows time service
2. Use VMware Tools

Use the Windows Time Service

If you will rely on the Windows Time Service, then it is recommended that the PDC Emulator of the forest root domain be a physical machine and its time service registry entries be modified to ensure that it synchronizes with an external time source. Details on all of the possible time service registry settings can be found here. To summarize, change the following on your forest root PDC Emulator:

a. Open the registry and go to HLKM\SYSTEM\CurrentControlSet\Services\w32Time
b. On the Config key, change AnnounceFlags REG_DWORD from 10 to 5
c. On the Parameters key, change Type value from NT5DS to NTP
NT5DS is used for time synchronization within the domain hierarchy whereas NTP is used to synchronize with an external time source. So you need to set your PDC emulator to use NTP and point it to a reliable internal time source such as a core switch, or an internet time source. If the PDC emulator is pointed to an internal time source, please ensure that that device is pointed to an external time source.
d. Change NtpServer value to an external time source
e. Restart time service
f. Force sync with w32tm /resync /rediscover

Once these changes are made on the physical PDC emulator, any additional DCs can be virtual machines and they will synchronize time with the PDC emulator.

Use VMware Tools

If you want to virtualize all your domain controllers, you will use VMware Tools, in essence the ESX servers themselves, as the time source. In this case, what you will do is:

a. Change the Type value in the registry from NT5DS to NoSync.
b. Have ESX host check an external time source
c. Configure VMware Tools on DCs to synchronize with the ESX host – this forces the machine to request CPU cycles, thus making sure the “timer ticks” to occur, preventing the clock drift problem. Not that VMware tools will play catch-up on time, but will not slow down if its gets ahead.

Other Points
Again, pick one method or the other, mixing them could result in unreliable time synchronization as virtual DCs are vMotioned amongst ESX hosts.

-Keep a watch on your replication topology using Replmon, Repadmin, DCDiag, etc.
-Make sure you have system state backups and perform all Active Directory restorations in accordance with Microsoft best practices.
-Do not recover a domain controller from a backup copy of an old virtual disk as the database revision level is not reset if restoring from an old clone.
-Do not use snapshots as this could cause corruption and performance degradation within Active Directory, plus, I read that Microsoft will not support a DC with a snapshot though I have not verified that recently.
-Set the Restart Priority of your virtual DCs to High and set Isolation response to “Leave power on”
-Use DRS Anti-Affinity rules to ensure DCs are running on different ESX hosts. With vSphere 4.1, DRS Anti-Affinity rules will recognize more than 2 VMs. Prior to 4.1, you could add many servers into a given DRS rule, but it would only work with the first two.

Finally
Once again, there is no right or wrong answer to virtualizing your domain controllers though you may find it interesting, as I did, that VMware has a 48 DCs, 47 are virtual and 1 is physical. The physical domain controller is the Forest PDC emulator.

2 Comments

Filed under Active Directory, Microsoft, VMware

2 responses to “Do you virtualize all of your domain controllers?

  1. Funny, we have all of our DCs virtualized WITH Hyper-V. It's a great product

  2. david@crookie.com

    If you have all domain and DNS servers virtualised and you have a critical network failure you can have fun trying to get stuff started.
    Always good to have one physical domain controller so you can resolve DNS! Or run a domain controller on XenServer.

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