There have been a number of concerns when it comes to virtualising domain controllers. The biggest of these is KB888794, which is an updated version of an article that I first encountered years previously, maybe in 2004.
USN Rollback
Basically, we had to treat any virtual domain controller like it was a physical installation. That meant:
- No snapshots
- No recovering the DC from VM (host/storage level) backups
- Don’t do anything to manipulate the virtual DC’s VM storage, such as copy/clone/etc
This was because the VM would “time travel”, effectively screwing up the USNs that are used to track AD object replication and possible cause the reuse of RID pools – in other words, completely frakking your AD and making you wish that you had paid up for that Microsoft Premier support contract.
Physical DC Required
One of the frustrating things, especially for small medium enterprises (SMEs) or smaller branch offices was that they need a local physical domain controller to enable a Hyper-V cluster. This company might only need to hosts, but had to add another physical machine (small as it was) to enable the cluster to function.
That was the scenario up to now. Enter Windows Server 2012.
Bootstrapping
Windows Server 2012 Failover Clusters have a new feature called bootstrapping. It’s been mentioned in public but I’ve not seen any documentation on it yet. In short, this allows a failover cluster to power up and start working without the presence of a physical domain controller. The premise is that you instead run virtual domain controllers, hosted on the Hyper-V cluster itself.
That means that you don’t need the physical domain controller. That’s a major saver for the SME or the branch office.
Virtual DCs are OK
If we’re OK with the idea of virtual domain controllers, then how do we deal with them? How do we back them up easily? In a true cloud where there might be a one-size-fits-all backup policy, how do admins (with zero knowledge of VM contents/roles) safely backup virtual domain controllers that might be created legitimate by the cloud’s tenants?
VM-GenerationID and Safe DC Virtualisation
Microsoft has come up with a new mechanism called VM-GenerationID (also seen documented on TechNet and blogged as Generation ID, VM Generation ID, VM-Generation ID and GenID). It is an attribute called msDS-GenerationID of the DC’s computer object in AD. This is normally kept in sync with the directory information tree (DIT) if everything is OK with the replication of the DC.
If something happens to the DC VM like a snapshot is applied or a backup of the VM is restored, then the VM effectively travels back in time, potentially causing a USN rollback and enabling RID reuse. But, the DC compares the VM-GenerationID and the DIT version number. If they are different then the DC is aware there is a problem. The RID pool is discarded, a new one created, and a USN rollback is prevented.
Windows Server 2012 Hyper-V is the only hypervisor at this time to support this feature, and the virtual DCs must be running Windows Server 2012.
But There’s More – Rapid Deployment of DCs
Wouldn’t it be nice if you could clone domain controllers? Normally you cannot. But this new VM-GenerationID feature, combined with some other work done by Microsoft in WS2012, enabled you to export/import virtual DCs to clone new DCs with very little effort.
The process is simple enough:
- Have a PDC Emulator that is running WS2012. This DC will not be cloned.
- Create a new virtual DC running WS2012.
- Add the new template DC to a domain security group called Cloneable Domain Controllers. This allows domain admins to restrict which (if any) DCs can be cloned.
- On the template DC Run Get-ADDCCloningExcludedApplicationList to see if any installed programs/services on the DC can be cloned (check with vendors). Uninstall any that cannot support cloning.
- Run Get-ADDCCloningExcludedApplicationList –GenerateXml on the template DC
- Back on the template DC, run New-ADDCCloneConfigFile to create an XML answer file to configure name, IP, etc, for the new DC VM that you are about to create.#
- The last step creates a file called DCCloneConfig.xml. Place this in either the directory where the DIT resides, %windir%NTDS, or the root of a removable media drive (maybe a SCSI attached blank VHD?)
- Stop and export the template VM.
- Import the VM to crate a new DC VM.
- Start the new VM, and you should now have a new DC.
I haven’t had a chance to try this out yet. I’ll try to update this if I find the MSFT TechNet page is lacking.
Summary
What all this means is that with Windows Server 2012 and a hypervisor that is VM-GenerationID aware (WS2012 Hyper-V) then you can safely virtualise your domain controllers, and treat them just like any other VM, something that is of great importance in a true cloud.
