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.
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.
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.
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.
7 thoughts on “Virtual Domain Controllers and Windows Server 2012 Improvements”
Can you comment on Dynamic Memory use with Domain Controllers?
I’ve seen that DM with SQLserver is unlikely to balloon down, as SQL hangs on to available RAM, and Exchange Mailboxes supposedly won’t play, but will DM break a DC?
A separate source said DCs aren’t supported. I can understand SBS as it contains the two roles I just mentioned (Essentials eliminates Exchange), but what about member DCs?
SBS is not supported: Exchange mailbox. DCs are supported.
My issue with virtual DC is joining the physical host to the domain so I can run exchange 2013 on it. This would make the physical controller dependant on the virtual DC after a restart and since the physical comes up first it won’t find the DC!
Is there a way around this or do I end up with one physical standalone server and two virtual servers (DC and then exchange)?
I would love to do this with Hyper-v server 2012 but the whole powershell install of an image scres me over.
Seriously!?!?!? You want to run Exchange on the host management OS? Stop working in IT. Now. Please.
Haha good one! this made me laugh my ass off!
I know it is an old post but you should certainly change career. Exchange on Management host lol so funny!!!
Thank you for the great post. I have learned a lot about licensing, backup and now the virtual DC.
I am completely new to Hyper-V. Sorry, if my questions are stupid. I have newer installed a Windows 2012 R2 with enabling the Hyper-V role. But I would like to try. I am doing a little planning. I would like to try building a Hyper-V cluster, with failover, live motion, backup. All the fun stuff. I have 2 old IBM x3650 servers with local storage. I was thinking 3-4 VM´s. A domain controller, an exchange server, a RDS server, a file server/Database server. But I am wondering about the domain controller.
From your article I learned that I should make a virtual DC. But would I join my physical hosts to the domain? Or are they best left as stand-alone?
Is it even possible to use local storage from 2 psychical servers to build a failover cluster?
You have to use shared storage to store HA VMs. Your cluster nodes must join a domain. You can run your DCs as VMs on the clustered nodes. I prefer to run them as non-HA VMs that are stored on local storage on the hosts, and all other VMs are HA running on the shared storage.