So you wanted to deploy Domain Controllers faster...Now you can!

A Domain Controller must have a unique name, invocation ID, and security identifier (SID) in the entire forest.
Up to Windows Server 2008 R2 promoting "syspreped" standalone images multiple times, was the fastest you could go in order to deploy a large number of Domain Controllers.
Sysprep was needed for ensuring that the deployed images were unique. Yes, scripts and answer files could be used for unnattended deployment in order to minimize administrative ovehead and deployment times.

As you could guess from my previous post, Microsoft has introduced new features in Hyper-V and Windows Server 2012 that allow to do things with Virtualized DCs that before were impossible.
This has became possible due to the introduction of an identifier called VM-Generation ID on the Hypervisor driver and the corresponding attribute in AD (msDS-GenerationID).

The feature I want to tell you about is VDC Cloning.

Now a Cloned Windows Server 2012 Domain Controller automatically executes Sysprep and uses the existing NTDS and SYSVOL data for promotion (similar to IFM - Install from Media). Additionally, you may create a configuration file (DCCloneConfig.xml).
Then just need to copy or export the source VDC and it's done.
You get faster deployment, scalability and easier disaster recovery.

Security wise, Domain Admins select DCs that can be cloned.
The Hyper-V administrators can only deploy the approved cloned DCs thus ensuring that unauthorized users cannot create rogue DCs.

The following table exemplifies how VDC Cloning is achieved:

So in a nutshell cloning succeeds the following will happen:

If both IDs don't match and a DCCloneConfig.xml file exists. (If xml file doesn't exist then VDC performs Snapshot safe restore - please refer to my previous blog for more information).

DSRM boot flag is set (to prevent boot into production in case cloning fails)

Then VDC checks for VDCisCloning DWORD under NTDS parameters reg key, and if it doesn't exist NTDS invalidates RID pool and resets Invocation ID; if exists then cloning has failed before (and went to DSRM as a safety mechanism) and this a re-attempt of cloning.

The Cloned VM gets the configuration settings (from DCCloneConfig.xml) and all ADDS related services are stopped.

Time synchronization is enforced (using DOMHIER) and Kerberos tickets are purged.

All FRS/DFSR database files are deleted (Not the SYSVOL content which will be used later for pre-seeding in order to minimize SYSVOL replication traffic) and services set to start automatically.

The cloned VM is renamed and DC promotion starts using the existing NTDS.DIT file as source (which will minimize replication traffic later).

Gets a new RID pool from the RID Master.

New Invocation ID and NTDS settings are created.

Starts inbound replication.

FRS/DFSR services start and non-authoritative restore of the SYSVOL is triggered.

Enables DNS client registration.

Runs Sysprep (DefaultDCCloneAllowList.xml determines which Sysprep modules are run)

Once promotion completes the DSRM boot flag is removed, the DCCloneConfig is renamed (will prevent it from being read during reboot),

the VDCisCloning DWORD removed and sets "VDC Cloning Done" to 1.

The value of VM-GenerationID (from HV) is copied to the VDC computer account VM-Generation ID (msDS-GenerationID attribute).

Finally once the VDC reboots it starts advertising itself as a DC.

Note: Currently, this feature only works on Windows Server 2012 Hypervisor or HV2012.

Hope this helps on your future DC deployments and feel free to comment.

Thanks

Paulo

Comments

• Anonymous
  January 01, 2003
  Nice one.

• Anonymous
  May 15, 2015
  Hello my name is Paulo Viralhadas and I'm a Premier Field Engineer at Microsoft.
  On one of my