Clones, Clones, Clones!
When people think of cloning, Dolly the Sheep comes to mind. Yet the 1996 event was not anything new. It has always been a drive in human nature — what if we can just make a replica with all the life experiences and memories. Cloning new Domain Controllers was not possible until Windows Server 2012. They could not be snapshotted, copied, or cloned. It could only be accomplished by creating them from scratch, that is, if you didn’t want to cause serious problems for your directory. Windows Server did not support cloning by just copying the .vhd or .vhdx files. But Windows Server 2012 has a pathway to the cloning process that ensures that domain integrity and data are kept intact.
Before you begin to clone a virtualized domain controller you need to make sure that your environment meets the following requirements:
- PDC emulator FSMO role hosted on Windows Server 2012 or Windows Server 2012 R2 domain controller
- PDC emulator available during the cloning operation
- Clone source and target of Windows Server 2012 or Windows Server 2012 R2
- Virtualization host platform supports VM-Generation ID (VMGID)
Supported Microsoft virtualization host platforms:
Microsoft Windows Server 2012 with Hyper-V feature
Microsoft Windows Server 2012 R2 with Hyper-V feature
Microsoft Windows Server 2012 Hyper-V Server
Microsoft Windows Server 2012 R2 Hyper-V Server
Microsoft Windows 8 with Hyper-V client feature
Microsoft Windows 8.1 with Hyper-V client feature
Important: Unsupported restores
Virtualized domain controllers do not support safe restores or cloning by manual copying of VHDs over existing files or by VHD file restore using file backup or full disk backup software.
Preparing the source domain controller
After you verify that the environment meets the minimum requirements, you need to prepare the source domain controller.
- The domain controller needs to be authorized for cloning by making it a member of the Cloneable Domain Controllers security group in Active Directory. You can use the Active Directory Administrative Center console, Active Directory Users and Computers, or the Windows PowerShell ActiveDirectory module to assign the source domain controller to the security group.
- Identify any applications that will prevent cloning by running the Get-ADDCCloningExclusionApplicationList cmdlet. DCCloneConfig.xml is an XML configuration file that contains all of the settings the cloned DC will take when it boots. This includes network settings, DNS, WINS, AD site name, new DC name, and more. This file can be generated in a few different ways.
- Any applications or services identified must be either removed or added to the CustomDCCloneAllowList.xml file. After you remove any services or applications that don’t support cloning, you can use the -GenerateXML parameter to create the CustomDCCloneAllowList.xml file. The inclusion list was written to ‘C:\Windows\NTDS\CustomDCCloneAllowList.xml’. For applications that are flagged by the Get-ADDCCloningExcludedApplicationList cmdlet,
- Microsoft applications or services, such as the DHCP Server role should be removed, not added to the CustomDCCloneAllowList.xml file.
- For third-party applications verify with the vendor or remove them to be safe.
- Remove any stand-alone MSAs from the source server. Group MSAs (gMSAs) support cloning, but stand-alone ones do not. Use Get-ADComputerServiceAccount to identify any MSAs and use Uninstall-ADServiceAccount to remove the accounts. You can read the accounts after you finish the offline cloning operation by using the Install-ADServiceAccount cmdlet. Create the DCCloneConfig.xml file by using the New-ADDCCloneConfig cmdlet, which creates the XML file based on the options you specify in the command New-ADDCCloneConfig. The final step to prepare the source computer for cloning is to shut it down.
Creating the cloned domain controller
After the source domain controller is shut down, you can copy its VHDs by using File Explorer, Xcopy.exe, or Robocopy.exe to the new location; or use Hyper-V export. Please remember to remove any snapshots prior to cloning, and merge any differencing disks prior to importing or creating the clone domain controller. After the files for the cloned domain controller are copied, you can restart the source domain controller.
Create the new target virtual machine (VM)
Create your new VM by using whatever method you prefer. For single-disk VMs with a single network adapter, it’s probably easiest to rename the copied VHD and create a new VM that uses it. Start the target cloned VM, and the cloning operation automatically completes. When the cloning is complete, both the original source domain controller and the new cloned domain controller are in the Cloneable Domain Controllers security group. They should be removed from this group except during active cloning operations.
Using the cloning feature assures a more successful use of your time and effort and leads to consistent deployment of domain controllers. You now have a cloned copy of your domain controller ready to do your bidding. If you need any additional information, you can find it here.