Event ID 2095 USN rollback: a domain controller restored from a snapshot

Fix it now

Event ID 2095 is a domain controller reporting that a partner received replication data from it using already-acknowledged USN tracking numbers. Microsoft names an improper restore as the most probable cause. There are three documented recovery options, so read them before you demote anything.

reg query "HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" /v "Dsa Not Writable"
netdom query fsmo
repadmin /replsummary

1. Confirm the quarantine: a Dsa Not Writable value of 0x4 confirms a detected rollback. Do not delete that value, and do not try to restart replication.
2. Check whether Net Logon is paused on that DC. Microsoft documents that pause as the deliberate consequence, taken to stop the DC originating any more updates.
3. Decide between the three documented options before acting: remove the DC from the domain, restore a system state backup taken before the rollback, or – for a virtual DC on Hyper-V – restore using a snapshot as the backup source or assign a new invocation ID.
4. If you are removing it and it holds operations master roles, seize them first: ntdsutil, roles, connections, connect to server <healthy dc>, quit, then the seize command for each role.
5. Then force-demote it with Uninstall-ADDSDomainController -ForceRemoval, clean its metadata from a healthy DC, and rebuild.

Seizing a role needs the right group: Enterprise Admins for the naming master, Schema Admins for the schema master, and Domain Admins for the infrastructure master, PDC emulator and RID master.

If the DC is out of the forest and a rebuilt one is replicating, stop here. The next section explains what a rollback does to the arithmetic and why the damage is invisible from the affected machine.

Why it happens

Every DC stamps each originating change with an increasing update sequence number, and every database instance carries an invocation ID. Partners remember the pair: I have seen changes up to USN N from invocation ID X. Restore through an Active Directory-aware path and the DC is given a fresh invocation ID, so partners discard their old high-water mark and resynchronise cleanly.

Apply a checkpoint or write a virtual disk back by hand and none of that happens. The USN counter jumps backwards while the invocation ID stays the same, so the DC starts issuing numbers its partners have already recorded as processed. Every one of those changes is silently ignored. Accounts created, passwords set and memberships changed on that DC after the rollback point exist nowhere else and never will.

Event 2095 is the detection, and its wording is worth reading in full: because the remote DC believes it has a more up-to-date database than the local DC, it will not apply future changes from this DC or replicate them onward, and if not resolved immediately the databases will diverge in users, computers, trust relationships, passwords, security groups and group memberships. Microsoft’s stated most probable cause is the improper restore of Active Directory on the local domain controller, and its stated user action, where that is what happened, is to forcibly demote the DC.

Full reference

Reading the evidence

Do not modify or delete the Dsa Not Writable value to bring the DC back. Doing so leaves the domain controller unsupported and lets it resume originating changes with reused USNs that partners will permanently ignore. The divergence becomes both permanent and invisible.

The three documented recovery options

Seizing the roles, with the right credentials

The sequence is ntdsutil, then roles, then connections, then connect to server <fully qualified name of a healthy DC>, then quit, and then the seize command. If the machine was not the RID master and you try to seize that role, you get a prompt asking whether to continue despite being unable to synchronise with a partner.

Metadata cleanup, three ways

1. Active Directory Users and Computers: connect to a replication partner, expand Domain Controllers, right-click the computer object, Delete, then confirm that the DC is permanently offline and cannot be demoted, and let it move any operations master roles.
2. Active Directory Sites and Services: expand the site, Servers, the server, right-click NTDS Settings, Delete, confirm the same prompt, then delete the server object itself.
3. ntdsutil: metadata cleanup, connections, connect to server <partner>, quit, remove selected server <name>, then quit out of both prompts.
4. If any of those returns access denied, clear “Protect object from accidental deletion” on the computer object and on the NTDS Settings object, then try again.
5. Confirm afterwards that the DC no longer appears under Domain Controllers and that its server object has no NTDS Settings beneath it.

Commands worth having open

Three event IDs in this article that Microsoft does not publish

Event ID 2103, Event ID 1084 and Event ID 1173 are all quoted in USN rollback material and none of them has a published meaning this article could find. They are recorded as such below. It does not matter much, because the two pieces of evidence that decide this case – the Dsa Not Writable value and the paused Net Logon service – are both documented and both survive log rotation, which the events do not.

Every code this article covers

Confirm the fix worked

1. No new Event ID 2095 appears on the rebuilt DC after a full day in service.
2. The Dsa Not Writable value no longer exists under the NTDS Parameters key.
3. The Net Logon service is running rather than paused.
4. repadmin /replsummary shows no failures in either direction for the new DC.
5. net share lists SYSVOL and NETLOGON, and the DC advertises correctly.

Questions people ask about this