An Active-Directory domain controller running as a virtual machine hosted by a compatible hypervisor is able to detect when it has been restored from a snapshot, thanks to the Virtual Machine Generation ID feature. In this case, it goes into a safe passive mode before retrieving the latest changes from other domain controllers (to avoid USN rollback issues, RID reuse, etc.). The same can be observed on the DFS-R side.
💡 This is a practical safety feature in production environments, but it can create tricky issues in labs and even break them… Let’s see how to disable it (in labs only)!
Which hypervisors support this feature? 🔗
Hypervisors known to implement this are recent versions of:
It doesn’t seem that VirtualBox implements it, but I didn’t test.
You can check if your current environment supports it or not, simply by taking a snapshot and restoring it. Then wait a couple minutes and look at the logs to see if you spot related events like shown in the rest.
How it works 🔗
This mechanism called “virtualization safeguard” is available since Server 2012. It’s based on the “Generation ID” parameter which is stored in the VM metadata, modified at each snapshot restore (and import, and migration), and which is exposed to Windows via a virtual device.
The last known value is stored in the “msDS-GenerationID” attribute of the machine object of each DC (note: it isn’t replicated!)
Get-ADObject -LDAPFilter '(msDS-GenerationID=*)' -Properties msDS-GenerationID
The DC therefore checks the value exposed by the hypervisor and the one stored: if there is a difference it means that there has been a snapshot restore. The detection is immediate even without rebooting (e.g. snapshot when the DC is running).
🔎 Observations 🔗
Following a snapshot restore, we have several alerts in the logs:
- detection of the change
- DFS-R triggers a non-authoritative restore
- RID pool invalidation
Then the new value is stored in the AD:
In the meantime, since the RID pool is invalidated, we can no longer create any object (and therefore any trust for example):
C:\> net user login password /add
System error 8208 has occurred.
The directory service was unable to allocate a relative identifier.
When is it useful, and when is it safe to disable it? 🔗
⚠️ You should never disable AD virtualization safeguard in a normal production environment. Except in certain disaster recovery scenarios as instructed by Microsoft.
However it’s perfectly fine in lab environments 😉 It’s even necessary for example if you have several domain controllers and you snapshot and restore all at the same time: otherwise, they’ll all stay stuck in a passive situation waiting from another DC in primary mode, which will not exist, hence ending in a deadlock situation! So my advice, for labs only, is to disable this feature and then snapshot the whole lab at once, and when you restore, restore all the snapshots at once too. The issues it normally prevents only occur when only a part of the domain controllers is restored and so is in a different situation in time than the rest.
A domain with a single domain controller will show the same events, but since it is alone, it will quickly recover from itself in a few seconds so you should not have any problem when restoring those.
➡️ Deactivation 🔗
This is a very good feature in production, but annoying in lab when you restore snapshots often and you take the effort to do it correctly (restore all DCs at the same time, from simultaneous snapshots). Fortunately, it can be blocked.
The best technique I’ve found, is to disable the “Microsoft Hyper-V Generation Counter” virtual device by blocking its driver:
Set-Service gencounter -StartupType Disabled
After a reboot you can clearly see that the device is disabled:
We can therefore restore snapshots without triggering this safety 👌
Surprisingly, VMware hypervisors (Workstation, vSphere) expose this generation ID to the virtualized OS through an identically named “Microsoft Hyper-V Generation Counter” virtual device (provided that it is a recent version with compatible VMware Tools installed). So the deactivation procedure is the same. Just note that you will need to first enable “Show hidden devices” in the View menu to see it: