One of the obvious reasons of virtualization is the independence of
virtual machines with hardware. It is very simple to clone a Virtual Machine (VM)
in a virtualized infrastructure.
But can we clone any VM?
It’s not easy to answer this question. The smart answer would be to
say as often: "It depends".
Until the 2012 version of Windows Server, clone a VM hosting ADDS
(Active Directory Domain Services) was forbidden. Indeed, clone or restore a Domain
Controller, could certainly cause a "USN rollback".
One of the major benefits in Microsoft Windows 2012 Server version is
the VM-GenerationID.
It’s an identifier encoded in 128 bits and provided by the hypervisor
through a specific driver.
You can check inside a VM if you’ll be able to clone a Domain Controller.
Let’s explore the device manager of a VM hosted by Hyper-V hypervisor running on a Windows 8 machine. Here you can see
how this test lab was created.
If you see the device "Microsoft Hyper-V Generation Counter", your
hypervisor will be able to manage the VM-GenerationID
and thus you will be able to clone a Domain Controller.
The VM-GenerationID is
generated and stored on the Domain Controller as an attribute of the Active
Directory database. This attribute is not
replicated.
The VM-GenerationID is
recorded in the Active Directory database NTDS.dit as the attribute msDS-GenerationID.
You can see it by logging on the DC you want to check and display its
attributes. You can easily do this via ADUC or ADAC.
1) Prerequisites
Clone a DC should meet the following prerequisites:
- As we have just seen, your hypervisor must support VM-GenerationID. This is the case with Hyper-V running on Windows 8 and on Windows Server 2012.
- The DC source must be running on Windows Server 2012
- The DC source can't hosted the PDC emulator role. In addition, the DC which hosts this role must be available and must be running on Windows Server 2012.
Though, you must have at least two DCs in your infrastructure to begin cloning a DC.
2) Prepare the source DC
To clone a DC, you must first prepare it to be cloned. The first step is to add your source DC to the security group "Domain Controllers Cloneable". You have several options to do this.
The first through the ADAC or even ADUC.
The second way is to do it via powershell.
Add-ADGroupMember "Cloneable Domain Controllers" "CN=DC02,OU=Domain Controllers,DC=LABO,DC=COM"
Ok, our source DC is now a member of the security group "Domain Controllers Cloneable". We're going to continue to prepare it.
Technet tells us that we need to launch a first command before starting the cloning process. Indeed, we need to determine what programs and services are not present on the default supported list "DefaultDCCloneAllowList.xml" or a user-defined inclusion list named "CustomDCCloneAllowList.xml" and thereby not supported by the cloning process because it have not been evaluated for cloning impact.
Get-ADDCCloningExcludedApplicationList
The result of the command is pretty clear in my case: "No excluded applications were detected". We can go further. However, in some cases you need to run a second command to generate your own .xml file containing the list of applications or services you want to add (because supported).
Here is an example (launched on a lab test running ESXi 5.1).
We type a second command to generate the .xml file.
Get-ADDCCloningExcludedApplicationList -GenerateXml
We can find the generated .xml file "CustomDCCloneAllowList.xml" in "C:\Windows\NTDS\".
To complete the warm-up, we have to launch a one last command:
New-ADDCCloneConfigFile -Static -IPv4Address "192.168.1.12" -IPv4DNSResolver "192.168.1.10" -IPv4SubnetMask "255.255.255.0" -CloneComputerName "DC03" -IPv4DefaultGateway "192.168.1.1" -SiteName "Default-First-Site-Name"
This command will generate a new .xml file: "DCCloneConfig.xml". By enter this command, we have specified the future cloned DC name and its network configuration.
The cloned DC must be on the same site.
Let's edit the configuration file of the DC02 virtual machine:
We find the number "genreration_id" with this hexadecimal value : "5683b796635a6015936e3117daa5b751".
The value for the msDS-GenerationId attribute is 51 B7 A5 DA 17 31 6E 93. By inverting the value found in the xml file of the virtual machine we find the same value 936e3117daa5b751 -> 51b7a5da17316e93
3) Export of the prepared VM and import in the new VM
Shut down the DC DC02 we just prepared.
In Hyper-V, select the VM to export (DC02 in this case) and choose the option "Export..."
Then, simply specify where you want to export your VM.
I've created, for this lab, a Export folder under the folder Labo on my G:\ disk which is, actually, a virtual disk hosted by a Synology NAS.
Let the export finished and then you get the tree Hyper-V created.
A .vhdx has been exported..
And the .xml configuration file.
Now, the import step. Select your node and "Import Virtual Machine...".
The import process is very simple "Next >"
"Browse".
Select the cloned VM root folder, here, for the example DC02.
"Next >".
Hyper-V detect a VM and "Next >" ;-)
We want that Hyper-V create a new unique ID "Next >".
>Store the VM where you want "Next >"
Where you want to store the .vhdx.. "Next >"
It's finished! Check the review of the import and click on "Finish".
Hyper-V begins the importation process.
Once the import is complete, if you edit the .xml configuration file of the imported VM, you can observe that the generation_id field has been modified.
DC02 .xml
DC03 (imported VM) .xml
Rename the VM. Right click on the imported VM and click on "Rename..."
It's done ! Start DC02 and then DC03.
Starting of DC03...
The DC found out it was a clone, so it starts the cloning process.
DC03 restarts once.
Check the Sites and Services console. You can see the new DC.
And present also in ADUC and ADAC.
If the properties of DC03 (DC resulting from cloning) is edited, you can see that the VM-GenerationID is different from the source DC DC02.
4) Detailed cloning process
Technet explains exactly what happens during the cloning process. Here is the diagram published by Microsoft to explain it.
5) Cloning went wrong ?
In case your cloning is wrong, the source DC will restart in Directory Service Restore Mode (DSRM). You need to login locally and removed the flag for DSRM mode. Then cloning and restart after, obviously, correcting the error that prevented you to clone the source DC correctly.
You can do this in two ways.
b) If you are in CORE Edition, via the command shell
bcdedit.exe /deletevalue safeboot
6) Conclusion
This tutorial is now complete.
We can see the great interest of the VM-GenerationID addition by Microsoft. Yeah, because it also opens the way for snapshot DC.
Indeed, before this improvement, clone a DC could lead to serious inconsistencies in our AD database as shown in this diagram (source).
It is now managed as shown in the following scheme (source).
