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.

Concluding

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