When virtualizing Active Directory Domain Controllers in the past, we've needed to be very careful that we don't invoke any steps, such as applying an old snapshot, that could possibly cause USN rollback to occur in the state of a Domain Controller's replica of the AD database and risk AD corruption. Beginning with Windows Server 2012, we've incorporated a new VM-Generation-ID unique identifier as an additional attribute of a Domain Controller's AD computer object as well as the VM container that is running the virtualized DC instance. When a virtualized DC starts up, Windows Server 2012 checks for a match between the VM-Generation-ID recorded on the VM instance and the VM-Generation-ID recorded on the DC's computer object in AD. If there's a mismatch, Windows Server knows that a possible virtualization snapshot or imaging event has occurred and it dumps the current RID pool and USN for fresh information to protect the state of AD.
NOTE: The VM-Generation-ID attribute must be supported by the underlying Hypervisor being using to virtualize a Domain Controller instance for the scenarios in this article to be functional. VM-Generation-ID support is included with Hyper-V v3 in Windows Server 2012, and we're also working with VMware and Citrix to help them provide this support in future versions of their Hypervisors.
UPDATE: VMware now supports VM-Generation-ID capabilities in the following versions of vSphere 5.0 and 5.1:
As Sander Berkouwer points out on his blog, it is certainly critical to make sure that your VM is running the correct version of Hyper-V Integration Components ( or VMware tools if using vSphere ) to ensure that the VM will be able to properly obtain the current VM-Generation-ID from the underlying hypervisor in use.
CAUTION: Improperly cloning domain controllers in a production environment can result in issues that are difficult to resolve. I recommend that you test the below steps in an isolated lab environment to make sure that you are comfortable with the process and expected results before attempting to perform these steps in a production environment.
This is pretty cool stuff to protect our Active Directories, but how does this tie into Cloning a Domain Controller?
When attempting to clone a virtualized Domain Controller, the same mismatch in VM-Generation-ID described above will occur. We can use this as an opportunity to supply additional instructions to the new cloned copy of a Windows Server 2012 DC so that, when it first starts up, it configures itself as an additional Domain Controller in the same Active Directory forest and domain, rather than merely starting up as a raw copy of the original DC.
Why would I want to Clone a Domain Controller?
In large Active Directories, the process of adding a replica domain controller via DCPromo or Server Manager can take a considerably long period of time, due to the need for replicating the entire AD domain database (DIT) to the new Domain Controller. The newly introduced safe cloning process in Windows Server 2012 can speed this process dramatically when using virtualized Domain Controllers by allowing an IT Pro to safely clone an already replicated Domain Controller to a new virtualized instance. This can save provisioning time as well as save a great deal of time when recovering from certain disaster scenarios.
Cool! How do I Clone a Domain Controller with Windows Server 2012?
Have you tried this process in your own Lab?
Feel free to post comments below with your experiences and any questions that you may have!
Like this article? Subscribe to "IT Pros ROCK!" and stay up-to-date!