Australian cloud for business software — built and run in Sydney since 2003

NetLeverage
NetLeverage

Domain Controllers on VMware: Snapshots and Restores

Technical article
Backup & Recovery

Direct answer: a domain controller (DC) put back to an earlier disk state without Active Directory knowing can suffer a USN rollback: its later changes stop replicating, and replication tools can still report no error. Since Windows Server 2012, a DC on a hypervisor that provides VM-GenerationID (vSphere 6.x and later, per Broadcom) can detect a snapshot revert or a copy and apply safeguards: a discarded RID pool and a new invocation ID. Those safeguards limit damage. They do not bring back un-replicated changes, and Microsoft states they do not replace system state backups and the AD DS Recycle Bin. After any DC revert or restore, gather read-only evidence, do not assume safety from a missing warning, and take recovery decisions with an Active Directory specialist using Microsoft's documented procedures.

Why it matters

A DC's database is one copy of a replicated directory, and every other DC tracks how far it has read that copy. If a DC goes back in time while its partners remember the newer state, accounts, password changes and group changes can exist on some DCs and not others. Microsoft describes this as a silent replication failure (Microsoft Learn: USN rollback).

The conditions that create the risk are specific:

  • a DC snapshot reverted, or a DC image restored, by a method that is not Active Directory-aware;
  • a DC's disks copied to build another machine that can reach production DCs;
  • a guest older than Windows Server 2012, or a host without VM-GenerationID, where the safeguards do not exist.

How it works

USN, invocation ID and why rollback is silent

Each DC numbers its own changes with update sequence numbers (USNs). The invocation ID identifies the version of the database on that DC. Partners remember, per invocation ID, the highest USN they have received.

Microsoft's worked example: a disk image of DC1 is captured at USN 10. DC1 later reaches USN 50, fails, and is restored from the old image without a supported system state restore, so it keeps the same invocation ID. Its partners believe they already hold DC1's changes up to 50, so they do not request the new changes DC1 makes as it counts from 11 to 50 again. repadmin /showreps reports replication without error, and the event logs show no replication failure. Users and computers created on DC1 after the restore are missing elsewhere, and password changes made on DC1 do not reach other DCs (USN rollback).

When Active Directory is restored with Microsoft's supported methods, the invocation ID is reset and the other DCs adjust. That is the difference between a supported restore and a rollback.

What VM-GenerationID adds

AD DS stores the VM-GenerationID it sees in its database, against the DC's computer object in the attribute msDS-GenerationId. At boot, and when a snapshot is applied to a running DC, it compares the hypervisor's current value with the stored one. When they differ, it treats the database as a copy or restored snapshot and (Virtualized Domain Controller Architecture):

  • invalidates the local RID pool, so security identifiers are not reused;
  • sets a new invocation ID, so partners replicate its changes again;
  • performs an automated non-authoritative restore and updates the stored value.

The same page adds a condition: if the snapshot was taken while the DC was suspended rather than shut down, the AD DS service must be restarted to trigger a new RID pool request.

Microsoft's limits on safe restore (Virtualized Domain Controller Deployment and Configuration):

  • "Virtualized domain controller safe restore is not a replacement for system state backups and the AD DS Recycle Bin."
  • "After restoring a snapshot, the deltas of previously un-replicated changes originating from that domain controller after the snapshot are permanently lost."
  • Safe restore is not supported for disk files manually copied over existing ones, or for disk files restored by file backup or full disk backup software. Microsoft's wording names VHD and VHDX. This article does not present that as a VMware statement; it treats any restore that only replaces disks with the same caution.

Both cloning and safe restore require Windows Server 2012 or later guests and a host platform that supports VM-GenerationID. Broadcom KB 341662 states VM-GenerationID is supported by vSphere 6.x and later (Broadcom KB 341662).

Cloning is a separate, prepared operation

Supported DC cloning needs the source DC in the Cloneable Domain Controllers group, a reachable PDC emulator, incompatible applications handled, and a DCCloneConfig.xml file. Without that file, a copied DC on a VM-GenerationID host applies safeguards but keeps the source DC's identity; Microsoft says such a DC should be removed from the network as early as possible (Architecture). This article does not cover the cloning procedure.

What to read after a revert or restore (read-only)

These checks only read state. None was run for this article. Gather them on the affected DC and on at least one partner, and keep the output.

  1. How the DC was restored. From vCenter task history and the backup product's job record: was it a snapshot revert, a disk or image restore, or an Active Directory-aware system state restore? This decides which Microsoft guidance applies.
  2. Directory Service event log: Event 2095. Microsoft says a DC logs it when a source DC sends a previously acknowledged USN without a corresponding change in the invocation ID (USN rollback). It is evidence of rollback when present. Its absence is not proof that no rollback happened, because the event depends on that specific replication condition.
  3. Rollback quarantine marker: reg query HKLM\System\CurrentControlSet\Services\NTDS\Parameters /v "Dsa Not Writable". Microsoft calls the value 0x4 forensic evidence of a USN rollback. Read only.
  4. Net Logon state: Get-Service Netlogon. Microsoft pauses Net Logon on a DC in rollback quarantine.
  5. Replication report (repadmin /showreps, as named by Microsoft). A clean result does not rule out rollback.
  6. Object convergence. Compare recent objects, password changes and their replication metadata across DCs. Microsoft names different object counts and metadata as the visible sign of divergence.
  7. Platform prerequisites. Guest is Windows Server 2012 or later; host ESXi version within KB 341662's scope. These show safeguards could apply. They do not prove the safeguards ran for this restore.
  8. Backup evidence. Whether a valid system state backup made before the incorrect restore exists for this DC, and how recent its changes are.

The stored msDS-GenerationId value is used by AD DS for its own comparison. This article gives no query for it: no Microsoft page retrieved for it documents a read that proves a particular restore triggered the safeguards.

Decision guidance

Every recovery route below changes Active Directory. Each is a decision for the domain owner with a qualified Active Directory specialist, following Microsoft's current procedure, not a step to take from this article.

If there is no rollback evidence. Do not conclude the restore was safe from the absence of Event 2095 or the registry marker. Establish with the specialist: the restore method (step 1), whether generation-change safeguards apply, whether replication and object state converge across DCs, and which changes made on the affected DC after the snapshot exist on its partners. Microsoft states that only previously un-replicated changes from that DC are permanently lost. Changes that had already replicated survive on partners. Re-create only changes verified as missing, through a controlled plan with the owners of those accounts or objects.

If there is rollback evidence (Event 2095, Dsa Not Writable 0x4, paused Net Logon), Microsoft documents three recovery approaches (USN rollback):

Approach When Microsoft frames it as an option Prerequisites to confirm before deciding
Remove the DC from the domain and, if required, promote it again DC to be rebuilt At least one healthy DC; role holders known; global catalog role known; metadata clean-up and any role transfer planned by the specialist
Restore the system state from a good backup A valid system state backup exists from before the incorrect restore and holds recent changes Backup validity and age verified; Active Directory-aware restore method
Restore without a system state backup No suitable system state backup Specialist-led; Microsoft's procedure followed exactly; isolated rehearsal where possible

Before any approach: a current backup of the healthy DCs, the role holders recorded, and a rollback plan agreed.

What not to do

  • Do not delete or edit Dsa Not Writable. Microsoft states this puts the DC in a permanently unsupported state.
  • Do not revert the DC again while investigating.
  • Do not treat VM-GenerationID as a backup. It cannot bring back un-replicated changes.
  • Do not use DC snapshots as a routine recovery method. Microsoft's Hyper-V guidance says "Don't take or use snapshots of virtual DCs" (Virtualizing domain controllers with Hyper-V). That page is about Hyper-V; the reasoning, that a snapshot is not an Active Directory-aware backup, is not hypervisor-specific.
  • Do not start a copied DC on a network that can reach production DCs.
  • Do not demote, clean up metadata, or move or seize roles without the specialist's plan and a current backup.

Limitations

  • No step was run for this article. Lab validation and Active Directory specialist review are outstanding.
  • Microsoft's safe restore caveats name Hyper-V disk formats; KB 341662 is brief and does not describe safe restore behaviour on vSphere.
  • Time synchronisation and Kerberos are covered in separate articles. Forest recovery is outside this article.
  • Cross vCenter vMotion of a DC is covered by Broadcom KB 430834; a migration is not a rollback and is out of scope.

Acceptance checklist

  • [ ] Every DC runs Windows Server 2012 or later on an ESXi version within KB 341662's scope (prerequisite, not proof)
  • [ ] A current system state or full server backup exists for each DC, made by an Active Directory-aware method (AD Forest Recovery: backing up a full server)
  • [ ] A DC restore has been rehearsed in an isolated network
  • [ ] After any revert or restore, the read-only evidence above is kept for the affected DC and a partner
  • [ ] Recovery decisions recorded with the specialist's name and the Microsoft procedure followed
  • [ ] Only changes verified as missing were re-created, and a test object created on the affected DC is seen on its partners

Sources

Displayed dates as shown when accessed on 30 October 2026.

Related articles

Learning notes

  1. A USN rollback can be silent: replication reports and event logs can look clean while changes are missing.
  2. VM-GenerationID lets a DC notice a revert or copy, discard its RID pool and take a new invocation ID.
  3. Only previously un-replicated changes from that DC are lost; verify what is missing before re-creating anything.
  4. No Event 2095 is not proof of safety; the restore method and object convergence are the evidence.
  5. Recovery from rollback is a specialist decision among Microsoft's three documented approaches.