Tom Moser here with a post on one of the new ADDS features in Windows Server 2012; Virtual Domain Controller Cloning.
Until now, cloning, snapshotting, copying, or pretty much doing anything but rebuilding from scratch to a virtual domain controller wasn't just unsupported; it had the potential to be really bad for your directory. Cloning or restoring snapshots of DCs could result in USN rollbacks or lingering objects, just to name a couple of problems.
Starting in Windows Server 2012, we now support DC cloning as well as snapshot restoration of domain controllers. With the RTM bits available, I found myself rebuilding my lab and took the opportunity to document the process to demonstrate just how easy it is to clone virtual domain controllers with Windows Server 2012.
There are a few base infrastructure requirements to take advantage of DC cloning.
There are a few other steps and requirements and I'll take you through those now.
There's a new group in town. It's called Cloneable Domain Controllers and you can find it in the Users container. Membership in this group dictates whether a DC can or cannot be cloned. This group has some permissions set on the domain head that should not be removed. Removing these permissions will cause cloning to fail. Also, as a best practice, DCs shouldn't be added to the group until you plan to clone and DCs should be removed from the group once cloning is complete. Cloned DCs will also end up in the Cloneable Domain Controllers group. Make sure to remove those as well.
In the case of my lab, I planned to build out a whole bunch of Server Core DCs. I built a single DC running the GUI-enabled version of Server, then built a DC running Server Core. This DC, DC02, will be my source domain controller.
The first step in the cloning process is to add the source DC to the Cloneable Domain Controllers group. Here, I've used the latest version of Active Directory Administrative Center to add my DC to the group. Make sure to select "Computers" under Object Type in the object picker when adding the DC. Here, I verified that the group now contains my source DC, DC02. (Figure 1).
We're almost there. No kidding. Next, we need to create the config file.
There's one key difference between a cloned DC and a DC that is being restored to a previous snapshot: DCCloneConfig.XML.
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.
In my lab, I used the PowerShell cmdlet to generate the config. This is an easy, safe way to generate the file and ensures there won't be any issues during cloning.
On your Windows Server 2012 domain controller, fire up PowerShell. From there, take a minute to run Get-Help New-ADDCCloneConfig –Full and review the help page.
Now that you've thoroughly reviewed the help page, let's go through the steps. On DC02, I ran the following:
New-ADDCCloneConfigFile -IPv4Address 10.2.1.10 -IPv4DefaultGateway 10.2.1.1 -IPv4SubnetMask 255.255.255.0 -IPv4DNSResolver 10.1.1.10,10.1.1.11 -Static -SiteName CORPDR
This cmdlet will generate a config XML using the specified parameters, in this case IP information, AD site to use, and that it's a static IP configuration. The IP information provided to the cmdlet will be used by the new cloned domain controller when it begins cloning.
The cmdlet is going to do a few things prior to generating the configuration XML file. First, it's going to verify that the PDC is available and running Windows Server 2012 or later (one of the pre-reqs above). This check can be skipped by specifying the –Offline switch. You should only need to do this if a global catalog isn't available. Second, it's going to verify that the source DC (where you're running the cmdlet) is a member of the Cloneable Domain Controllers group. Finally, the cmdlet is going to check the DC for applications that may not support cloning. If any applications or services are detected (such as DHCP), generation of the config will fail. You'll see something like Figure 2 (below).
Figure 2 - Failed Clone Config Generation
The cmdlet warning text is pretty helpful. It tells us that applications were found that are not on the allowed list. What's on the allowed list? Good question. You can find it at C:\Windows\System32\DefaultDCCloneAllowList.xml. This list exists by default on Windows Server 2012 domain controllers and should not be modified. If you want to add a discovered application to the list, you'll need to generate a custom DC allow list.
Prior to generating the custom allow list, you'll want to review what applications actually caused the warning. Running Get-ADDCCloningExcludedApplicationList (tab complete is your buddy here) will show you that list. This cmdlet will dump out all of the services that were discovered while trying to generate the DCCloneConfig.XML (Figure 3). From here, you can make a decision; remove the discovered application or service or add the application to the custom allow list. Generally speaking, if it's a Microsoft service that has been flagged, as DHCP has been flagged in this example, you should not clone it. If a third party application is discovered and you've verified with the vendor that cloning is supported, then you can jump to Figure 4.
You've verified with the application vendor that the service is OK to clone. Generating the allow list is easy. Run Get-ADDCCloningExcludedApplicationList again, but specify the –GenerateXML switch.
The cmdlet generates the XML and writes it out to c:\windows\ntds, as the output shows. Viewing the contents in notepad shows this (Figure 5):
Figure 5 - Or you should just remove DHCP...
And that's what the custom allow list looks like. Again, you could use an XML editor to modify this, but should probably remove the application unless you have a specific reason to create a clone of the service and you've verified that the application supports cloning. Once you've generated the XML file, you can run New-ADDCCloneConfigFile again and it'll successfully generate your config. In my case, I used Remove-WindowsFeature and removed DHCP from my DC. Figure 6 shows the PowerShell commands for both removing DHCP as well as successfully generating my DCCloneConfig.
Figure 6 - That's a lot of green, so I think it's OK.
As the output shows, the XML file is written to c:\windows\ntds. That's one of three valid locations where the file can be placed for cloning. All three locations are:
The config file should have been written out to c:\windows\ntds. Viewing the content with Get-Content in PowerShell shows us what the config looks like (Figure 7). If you're familiar with XML-based configuration files, this should look pretty typical.
Now I've got the config file, I've removed the unsupported service and I'm ready to start the cloning process.
The last step now is to export the source virtual machine. This can be accomplished via PowerShell or the Hyper-V management console.
First, turn off the source DC then export the VM. I used PowerShell (Figure 8). Milt0rDC02 is the name I used in Hyper-V for DC02.
Now that I've exported the source DC, I need to import the VM. In PowerShell, I navigate to the path were I exported the VM and to the Virtual Machines subdirectory. There, I run Import-VM and store the result in a variable called $clonedVM. Milt0rDC03 is the name in Hyper-V I'll use for this new domain controller.
$clonedVM = Import-VM –Path <VM XML Path>.xml –Copy –GenerateNewId –VhdDestinationPath G:\VHDs\Milt0rDC03
With the Import-VM cmdlet (Figure 9), I specify the path to the VM XML file and use the –Copy and –GenerateNewId switches. The copy switch is going to leave my original export intact and the GenerateNewId switch will generate a VM ID that differs from the ID of the originally exported machine. I also had to specify a different VHD path using –VhdDestinationPath. This path is the directory where the VHD will be copied to. The VHD will import using the same name as the VHD from the export. In my case, this was Milt0rDC02.vhdx. The copied VHD will import to G:\VHDs\Milt0rDC03\Milt0rDC02.vhdx. These can be renamed and the VM reconfigured after the import is complete. You could also simply create a copy of the VHD, rename it, create a new VM, then attach the VHD to the new VM.
Once that completes, I'm able to quickly rename the VM (as it will retain the name of the originally exported VM) by using the Rename-VM cmdlet (see Figure 9).
That's it. From here, it's just a matter of turning on the DC and letting everything happen on its own.
If you've made it this far in the post, you're probably thinking "this seems pretty long and drawn out." Sure, I'm pretty long-winded, but we've actually only done two things here: Create a clone config file (which is fast, assuming you don't have any apps that aren't allowed) and create a copy of the source DC. Now we can power on the copied DC, our clone, and the rest should take care of itself.
I fire up the VM and after a minute or so of "Completing installation" I see this screen (Figure 10).
A few minutes of this and the DC will reboot. When it's up, you should see a new DC in the Domain Controllers OU and logging in to the DC should indicate that you're in normal mode and not DSRM. Now you'll want to take some time to verify that both NTDS and SYSVOL replication are working properly and that everything is responding as expected. If it checks out, you've successfully cloned your virtual domain controller.
At the beginning of the post, I mentioned that the hypervisor must support VM-GenerationID. VM-GenerationID is a property that is exposed to the VM via the virtualization drivers and is unique to that virtual machine. Each Windows Server 2012 domain controller stores its own VM-GenerationID in a property called msDS-GenerationId on the DC's computer object. This value does not replicate. If you try to view the value of msDS-GenerationId from another DC, you'll see that the value shows up as not set.
Figure 11, below, shows the value on DC02-CL0001. I had to connect directly to that DC in ADUC to see the value.
Each time a Windows Server 2012 domain controller boots, it compares the VM-GenerationID presented by the hypervisor to the value it has stored in the DIT. If they match, it boots normally. If they don't match, this indicates that the DC is a restored snapshot or a clone.
How does it determine if the VM is a restored snapshot or a clone?
Remember that DCCloneConfig.xml we created earlier? When the VM-GenerationID mismatch is detected, the next step is to check for that configuration file. If it exists, the cloning process starts. If that file doesn't exist, it's assumed that this is a restored snapshot and the restore process starts.
After, there's a bunch of "stuff" that happens which, for the sake of brevity, I'll cover in another post. The DC reads the config, modifies the domain controller configuration based on the settings in the DCCloneConfig.xml, and attempts to complete the cloning process. Here's where you might run in to issues, especially if you cheated and just dropped a config on another server without running the New-ADDCCloneConfig cmdlet. Some problems you might run in to are:
In each of those cases, the clone will fail and the DC will boot to Directory Services Restore Mode. Logging on to the DC and viewing the DCPromo.log file in C:\Windows\Debug should give you some hints on why it failed.
Assuming you didn't run in to any of those issues and your DC clone completed successfully, you're all done! If you didn't specify the –CloneComputerName parameter when you ran New-ADDCCloneConfig (which I intentionally left out), the DC will boot using a generated name. If you do specify that parameter, the given name will be used for the new domain controller. In the screenshot above (Figure 11), you can see that my DC is called DC02-CL0001. The source DC was called DC02. The cloning process will take the first eight characters of the source domain controller's name then append –CL000X. This value will count up for each clone. Once you get to 9999, you'll need to pick a new name to clone immediately followed by calling your TAM to brag about having 10,000 domain controllers. Since I don't plan on continuing to clone, I decided to rename the domain controller to DC03 and called it a day.
If you've made it this far, you'll now be able to successfully clone DCs in your environment. After each time through cloning, I mounted the exported VHD from the source VM, modified the DCCloneConfig.xml file, and created another copy of the VM. This process enabled me to very quickly create four copies of my original Server Core DC. I'll demo that in a future post.
I hope this post gives you an understanding of virtual domain controller cloning and the steps involved to make it work. In a near-future post, I'll cover the process with a little more depth as well as troubleshooting and safe restore. Thanks for reading!
Very Nice Article !
Nice post Tom, I've heard that vSphere 5.1 will support VM-GernationID.
Good blurb from Ned Pyle's "Understand and Troubleshoot Virtualizaed Domain Controllers" document
*****************From Ned's Doc, not taking credit for his work ***************
VDC safe restore is not a replacement for system state backups and the AD DS Recycle Bin. After restoring a snapshot, the deltas of previously un-replicated changes originating from that domain controller after snapshot are permanently lost. Safe restore implements automated non-authoritative restoration to prevent accidental domain controller quarantine only.
Mike, you're absolutely correct. Clones and snaps CANNOT be used as a backup and restore method. When the clone or restored DC comes online, it will replicate inbound from other DCs, so if there's some issue in the directory, the clone will get it as well.
Very well written article, Thanks Tom!!
i did everything but wen i start the new one it gives me same name as i did clone plus takes me to safe mode.
If the DC name remained the same and it booted to DSRM, the cloning failed. You'll want to check c:\windows\debug\dcpromo.log to see what might have caused it. Off the top of my head, it could be:
- PDC isn't available or is not a Windows Server 2012 domain controller
- Applications were found that are not in the default allowed list and there's not a custom allow list present.
- Source DC isn't a member of the Cloneable Domain Controllers group.
The log file is pretty descriptive and should tell you for sure what happened.
Good Information. Thanks a lot Tom Moser.
Excellent article - its one thing for MS to have coded and released this, but another thing entirely for it to be adopted. The latter is possible due to articles like this ;-)
I wonder how long it will be before non MS hyper visor vendors support VM-GenerationID's ;-)
Thanks! I think there are some interesting cases for using cloning. Like many features, we'll have customers that use it all the time and customers who barely know it exists :) Ultimately, I think the VDC safety processes elegantly handling snapshot restores is probably the best part. It'll prevent severe problems for our customers.
I do know that the latest version/update of ESX does implement VM-GenID.
Can you please spell out scenarios in which cloned DCs are better than ones created with DCPromo? It does look like a lot of work for something thanks
John - I'm sure Tom will respond but one scenario where this is efficient is in the case of a large deployment of new DCs during a domain upgrade (or new deployment).
Imagine being able to clone a ‘fleet’ of new VM DCs once you’ve done the hard work of the initial deployment/upgrade of your central DC(s). It is likely waaaaayyyy faster (and likely more precise, too) to ‘clone-out’ 75 VM DCs than to build/DCPROMO 75 DCs.
Hilde nailed it. All of this prep work only needs to take place on a single domain controller (every TSL - The clone source is only good for whatever your tombstone lifetime happens to be, which is likely 60 or 180 days). After this 10-15 minutes of work, with a quick script you can clone away.
Another use case for cloning is disaster recovery. In a DR situation, your first DC in each domain would need to be recovered with the standard forest/domain recovery procedures (link below). After that initial DC recovery, cloning can be leveraged to quickly expand capacity in each domain.
And, as Hilde mentioned - Consistency! You'll know they're all the same... of course you could monitor that using DCM in SCCM ;)
Thanks Michael and Tom for the good working scenarios.