Cases where VM-GenerationID doesn’t help make Active Directory virtualization-safe, Part 1

Reading Time: 3 minutes

Joe Richards posted an interesting blogpost a while ago on why Active Directory VM-GenerationID functionality is not an alias for Active Directory anti-USN Rollback functionality. In it, he makes some valid claims:

  • You are only protected in very limited set of very certain very specific circumstances.
  • The VM-GenerationID "triggers" are dependent upon the virtualization platform.  Different platforms could have different triggers, meaning you could have various levels of protection from different actions on various platforms.
  • He can list several actions off the top of his head that are not protected.

While I agree wholly with the first claim and partially with the second claim (since the VM-GenerationID whitepaper specifies the cases), the third claim got me thinking.

Let’s start off, by examining the table with the conditions listed in which the VM-GenerationID is changed. The table is a summary of the functionality every VM-GenerationID-capable virtualization platform needs to offer. It’s at the end of the previously mentioned whitepaper:

So, from this table, I can already envision a scenario where VM-GenerationID won’t make virtualizing Active Directory Domain Controllers any safer: Since the feature is implemented on the hypervisor level, changes in the networking and storage levels outside the hypervisor will not trigger the virtualization safeguards in Active Directory.


On the storage level

One way to let a virtualized Windows Server 2012-based Domain Controller trip on a VM-GenerationID-enabled virtualization platform is to shut down the virtual machine, replace its hard disk on the storage level (for example, with a SAN snapshot or by copying in using File Explorer) with an older copy of the hard disk of the same Domain Controller. After you start the virtual machine again, the virtual Domain Controller and its replication partner(s) will experience the same situation as before with non-VM-GenerationID-enabled virtualization platforms and/or virtual Domain Controllers running previous versions of Windows Server: a USN Rollback situation.

The reason why is quite simple. Even though the hypervisor maintains a VM-GenerationID value and compares this value in the Active Directory database (on the virtual hard disk of the Domain Controller) before every significant write action, both values don’t change when you perform an action outside of the hypervisor. The restored hard disk has the same VM-GenerationID value as the previously up to date hard disk, but the Unique Serial Number (USN) was rolled back during the restore.

Also, performing a SAN-failover, where the source SAN and target SAN are not completely in sync, might result in the same situation: it’s the virtual equivalent to restoring a disk snapshot (made with Acronis True Image, for instance) of a physical Domain Controller.



The Active Directory virtualization safeguards have been implemented at the hypervisor level. This leaves a couple of cases open, where the safeguards don’t kick in. Restoring the virtual hard disk to an existing virtual Domain Controller is the first case in this series.

Related blogposts

New features in AD DS in Windows Server 2012, Part 12: Virtualization-safe Active Directory New features in AD DS in Windows Server 2012, Part 13: Domain Controller Cloning

Further reading

Windows Server 2012 AD VM-Generation ID functionality is not…
Active Directory Virtualization Safeguards and Domain Controller Cloning with Windows Server 2012 at Microsoft TechEd North America 2012
Considerations for virtualizing all Active Directory domain controllers
TechNet Wiki – Windows Server 2012 : Virtualization Safeguards
Virtualization Updates to Active Directory 2012
Cloning Virtual Domain Controllers in Windows Server 2012
Steps to create a Clone of Domain Controller in Windows 2012

One Response to Cases where VM-GenerationID doesn’t help make Active Directory virtualization-safe, Part 1


    I am attempting to create a virtualized domain (2 or more VMs) in Azure for test purposes. I want to be able to stop/deallocate these VMs each night so I won't be billed for the VMs when they are shut down. However, deallocating the Azure VMs causes Service Healing to be performed by the Azure Hypervisor when restarting the VMs which then causes a change to the VM's VM Generation ID. This VMGenID change is then picked up by the DCs and the corrective action is applied.

    But, I do not want the corrective action to be applied. So, I must find a way to spoof the DC into thinking that the VMGenID has not changed. What I want to do is to make the NTDS service be dependent on a "FixVMGenID" service which will mount the AD/DS database (using dsamain.exe) and setting the msDS-GenerationId attribute to the value of the VMGenID that is read from the VM's BIOS. After this fix is done, the AD/DS database is dismounted and the FixVMGenID service will enter the running state which will then allow the NTDS service to start.

    I've gotten most of the FixVMGenID code written and tested. The only problem I am having is with the IADs::Put call to actually set the new msDS-GenerationId attribute value. The error code from IADs::Put is 0x80004005 which I believe is an "Access Denied." error. How can I get the appropriate access to be able to set the msDS-GenerationId attribute?

leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.