Active Directory Operations and recovery
Virtual domain controllers and rollback
Understand what VM-GenerationID protects during rollback, what it can't recover, and which hosting dependencies can stop recovery.
Replication needs a database incarnation
A DC assigns local update sequence numbers to changes. Partners track progress against the database’s invocation ID, which identifies its replication incarnation. If an unsupported rollback reuses old USNs under the same invocation ID, partners can believe they have already received changes that they have not. This is the core of USN rollback.
For replication identity and metadata inspection, start with:
repadmin /showrepl dc1.contoso.com /verbose
The DSA object GUID and invocation ID are different identities. A normal restore can change the latter without creating a new DC object.
VM-GenerationID lets the guest detect a rollback
On Windows Server 2012 and later, a compatible hypervisor can expose VM-GenerationID. When the identifier differs from the value stored in the directory database, AD DS performs safeguards including changing the invocation ID and discarding the RID pool. Microsoft’s virtual DC architecture describes the sequence.
Both the guest OS and hypervisor must support the mechanism. The VM booting successfully won’t tell you whether the restore changed the generation ID correctly. Check support for the hosting and recovery operation you’re using, then test the guest events and directory behavior.
Collect evidence of the safeguard
Record the guest’s replication identity and relevant events before and after the controlled restore:
Get-WinEvent -FilterHashtable @{
LogName = 'Directory Service'
Id = 1109,2170,2179
StartTime = (Get-Date).AddDays(-1)
} | Select-Object TimeCreated,Id,Message
Event 2170 reports a detected generation-ID change; 2179 reports setting the directory’s saved generation value. Event 1109 records an invocation-ID change, which can also occur during other supported restore operations. Read the messages and correlate the hypervisor action; one event number is not proof that all recovery steps succeeded. Microsoft’s virtual DC troubleshooting reference documents the event meanings and failure branches.
A safe restore can still lose changes
Changes originating on the restored DC after the snapshot and never replicated elsewhere are lost. SYSVOL and directory data also need to converge with healthy partners. The safeguards assume an appropriate writable source; restoring all DCs simultaneously is not equivalent to restoring one replica. Deployment guidance for virtual DCs explains these limits.
You still need application-aware backups and a rehearsed forest recovery plan. Decide which restore operation and recovery scope you’ll use before relying on the hypervisor safeguard.
Restore and cloning are separate intentions
A supported clone uses the source’s directory data to provision a new DC identity. It needs VM-GenerationID, source authorization to clone, a suitable available PDC emulator, clone configuration and compatible applications/services. Copying a VHD and changing the hostname doesn’t perform those steps.
The clone configuration file signals administrative intent. When the required generation-ID capability is absent, the documented cloning path can stop in DSRM rather than safely creating another DC. Retain the cloning logs and check each prerequisite before retrying. The virtual DC architecture separates cloning from safe restore.
Look for circular dependencies
Work through how the team will start the virtualization platform during a forest outage, reach its storage, resolve names and authenticate to its management tools. If all of that needs the DCs inside the platform, you can get stuck even when each component is healthy.
Plan independent failure domains, usable emergency credentials and a startup sequence. Whether one role holder is physical or virtual won’t answer those dependency questions on its own. Microsoft’s virtual hosting guidance discusses host and cluster dependencies.
Time synchronization is another dependency
VM-GenerationID is a replication rollback safeguard. It does not choose the time source. Inspect virtualization time providers and W32Time separately, particularly around suspend, resume, import and host recovery. See time service diagnosis.
Do not repair USN rollback with an old registry recipe
Don’t use a manual DIT-copy and Database restored from backup registry technique to make an arbitrarily rolled-back DC replicate. Keep the logs and database state, find healthy replicas and follow the supported rebuild or recovery procedure for the failure you have. Microsoft’s USN rollback guidance describes detection and recovery.
Validate consistency and the hosting operation
After the documented recovery, check directory replication in both relevant directions, SYSVOL initialization, advertising and representative authentication. Confirm the hypervisor’s storage and backup operations preserve the required semantics. A test of one checkpoint operation does not prove that an unrelated storage-level rollback, import or replicated-storage failover presents the same generation-ID behavior.