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:

  • VMware vSphere 5.0 Patch 4 (Build 821926, 9/27/2012)
  • VMware vSphere 5.1 (Build 799733, 9/10/2012)

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?

  1. Get the Bits! Download Windows Server 2012 so that you can follow along with the steps below in your own shop.
     
  2. Ensure that you are using a Hypervisor that supports the new VM-Generation-ID functionality, as described in my note above.
     
  3. Authorize the original source Domain Controller to be used as the source for cloning by adding it's computer object into the new "Cloneable Domain Controllers" Active Directory group
     
  4. Confirm clone compatibility with the services running on the original source Domain Controller by running the following PowerShell commmand:

    Get-ADDCCloningExcludedApplicationList

    Review the list of returned services and installed programs with your software vendors to determine if any of these software components will be affected by a change in computer name or computer SID.  You must remove incompatible software from the original source DC prior to cloning, or the process will fail.  For the remaining software, if it is compatible with the cloning process, run the following PowerShell command to update the compatible list of programs to include this additional software:

    Get-ADDCCloningExcludedApplicationList -GenerateXml
     
  5. Configure the original source Domain Controller with the instructions for configuring the new clone DC by running the below PowerShell command.  This command will record these settings in a file named DCCloneConfig.xml in the NTDS DIT folder ( C:\Windows\NTDS, by default ).  You can find a sample of this file located on your original source Windows Server 2012 domain controller at C:\Windows\System32\SampleDCCloneConfig.xml.

    New-ADDCCloneConfigFile
    -CloneComputerName "Name_of_New_DC"
    -SiteName "Name_of_AD_Site"
    -Static -IPv4Address "IP_Address_of_New_DC"
    -IPv4SubnetMask "Subnet_Mask_for_New_DC"
    -IPv4DefaultGateway "Gateway_For_New_DC"
    -IPv4DNSResolver "IP_Address_of_DNS_Server"
    -PreferredWINSServer "IP_Address_of_WINS_Server"

    For example, the command syntax for the configuration of a new DC named "VirtualDC2" in AD Site "ADSite01" with an IP address of "10.0.1.2" might look like:

    New-ADDCCloneConfigFile
    -CloneComputerName "VirtualDC2"
    -SiteName "ADSite01"
    -Static -IPv4Address "10.0.1.2"
    -IPv4SubnetMask "255.255.255.0"
    -IPv4DefaultGateway "10.0.1.1"
    -IPv4DNSResolver "10.0.0.2"
    -PreferredWINSServer "10.0.0.3"
     
  6. Shutdown the virtual machine of the original source Domain Controller to prepare it for cloning.  On Hyper-V v3, you can use the following PowerShell command to perform this task:

    Stop-VM  -Name "VirtualDC1" - ComputerName "HyperV1"
     
  7. Export the virtual machine of the original source Domain Controller to a folder.  On Hyper-V v3, you can use the following PowerShell command to perform this task:

    Export-VM -Name "VirtualDC1" - ComputerName "HyperV1" -Path "D:\VMExport"
     
  8. Copy the folder contents to a new Hyper-V host server where you will import the D:\VMExport folder to a new cloned VM.  Using your file copy tool of choice - I recommend ROBOCOPY which is included with Windows Server 2012.
     
  9. Import the VM on the new Hyper-V host and create a new VM-Generation-ID for the newly cloned VM copy:

    $vm = Import-VM -Path "D:\VMExport\VirtualDC1\Virtual Machines" -Copy -GenerateNewId

    NOTE:
    If Importing the VM to the same Hyper-V host as the original source Domain Controller or importing the same exported VM multiple times, you'll also need to specify new unique folder locations for each imported VM using the following command-line switches on the Import-VM command:

    -VhdDestinationPath
    -SnapshotFilePath
    -SmartPagingFilePath
    -VirtualMachinePath
     
  10. Rename the newly cloned copy of the VM

    Rename-VM -VM $vm -New-Name "VirtualDC2"
     
  11. Delete any VM snapshots that may have been present in the original source VM prior to exporting

    Get-VMSnapshot -VMName "VirtualDC2" | Remove-VMSnapshot -IncludeAllChildSnapshots
     
  12. Start your original source Domain Controller VM and your newly cloned Domain Controller VM.  As part of the initial startup process, your newly cloned Domain Controller VM will process the instructions recorded in the DCCloneConfig.xml file to configure itself with a new computername and new IP Address information.

 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!

HTH,

Keith