Cloning Virtual Domain Controllers in Windows Server 2012

One of the obvious benefits of virtualization is that because a virtual machine (VM) exists entirely in software, with no unique physical pieces, you should be able to copy (orclone) a VM and experience no loss in integrity. Cloning is a significant benefit of virtualization; you can quickly create new VMs without going through a tedious creation process every time. But can you clone a VM running any type of application? The answer to that question—as with so many other questions in life—is, “It depends." This wishy-washy answer makes sense when you look at the contents of a VM in layers and see what is unique in those layers.
 

AD Was a No-Clone Zone

A VM's component virtual disks and configuration are certainly designed to be cloned, but what about the base OS? Yes, that can be cloned, too, as long as it's not uniquely coupled to any physical components (such as a passthrough disk) and you resolve other potential conflicts such as the system's name and static IP address, if it has one. A domain-joined VM presents another conflict, in that the machine's security identifier (SID) is the same as the original. There are a number of workarounds for this conflict—from the Sysprep process to the Sysinternals NewSID utility—that will generate a new SID for the cloned VM. There are also application-level dependencies. In Active Directory Domain Service's (AD DS’s) case, the major constraint against cloning a VM is tied to the fact that each domain controller (DC) is an integral part of a larger whole, a distributed system of DCs. Even though a DC can easily be replaced if it fails, it's essential to keep the whole distributed system informed of each DC's status. Most of the time, the DC whose state has changed (e.g., has been recovered from a backup) notifies its replication partners. Relying on such self-checking has its drawbacks, however, and over time safeguards have been added so that if a DC detects certain behaviors—such as attempting to replicate attributes for an object that's already been deleted—with a replication partner, it will reject all further updates.
 

If you trick a virtualized DC in Windows Server 2008 R2 or earlier by performing virtualization operations to it that it’s not familiar with, bad things can happen. Judging from the high call volume to Microsoft Customer Service & Support (CSS), this kind of trickery is a common mistake. It's understandable, of course: If the technology lets you do it, it should be safe, right? As result of such mistakes, in the Windows Server 2012 product cycle, the Active Directory team set a high priority for making AD safe to virtualize: They introduced the VM-GenerationID (VM Gen ID) into the hypervisor and built relevant logic into the OS and AD. My July column “ Virtualization-Safe Active Directory in Windows Server 2012” goes into more detail about this solution.
 

Clones Equal Flexibility

But back to cloning. Making AD virtualization safe in Server 2012 also produced the side benefit of making it safe to clone AD. Cloning is an especially useful benefit for AD because it lets you quickly add capacity. Prior to Server 2012, the only way to add a DC to your AD forest was to create a new VM, then use Dcpromo to promote the VM to DC status. That method isn't such a big deal if you don't have a large AD forest with a correspondingly large ntds.dit directory database or if you have to only occasionally add or replace a DC—but if you're in a large or flexible environment, it really slows you down. If you can rapidly deploy new DCs, you have a big edge in quickly recovering a domain or forest in a disaster recovery situation, as I outlined in “ How Windows Server 2012 Improves Active Directory Disaster Recovery.” If you're building a private cloud, DC cloning will let you make the cloud authentication and authorization infrastructure as elastic as the rest of its capabilities. If you need to quickly spin up a test environment or add capacity to a branch office, DC cloning will do it for you.

Of course, any new feature that affects the security infrastructure must come with appropriate administrative and security restrictions. You can't let just anyone create another DC. The administrative challenge of any layered infrastructure is that whoever controls the lower layers can affect the upper layers. For example, the fastest SQL Server cluster in the world won't get much work done without network connectivity.

In a virtualized AD infrastructure, the hypervisor administrators have control over all VMs and therefore all virtual DCs (VDCs). It isn’t possible to restrict which DC a hypervisor administrator tries to clone; therefore, the AD team built safeguards into the cloning process so that it works only if a virtual DC that's been authorized as a clone source was used.
 

Cloning Procedure

Before you can clone a Server 2012 VDC, both the server hosting the source VDC and the destination host must support VM Gen ID. Currently, only Windows Server 2012 Hyper-V supports VM Gen ID, but VMware and Citrix have the specification to incorporate into their products. The PDC Emulator for the domain must also be running Server 2012 (but you can't clone it). Note that you can clone only a Server 2012 DC; you can't perform this operation on any earlier versions. And the fact that you have existing Server 2012 DCs means that you’ve already upgraded your forest and domain(s) to Server 2012, as I discussed in “ Windows Server 2012 Simplifies Active Directory Upgrades and Deployments.” At a high level, the steps to clone a DC are as follows:

Universal Appeal

Cloning is another welcome feature in AD for Server 2012. Whether you’re in a large shop looking to quickly add capacity, a midsized organization that needs to provide failover to branch offices, or a small business that will be using VDC cloning for AD disaster recovery, everyone can take advantage of this new capability.

Sean writes about cloud identity, Microsoft hybrid identity, and whatever else he finds interesting at his blog on Enterprise Identity and on Twitter at @shorinsean.