USN Rollback Detected — Event 2095

Introduction

A help desk ticket mentions a user whose password change from yesterday didn’t take – the old password still works on some logons and not others. Another ticket says a security group someone created last week doesn’t exist on a domain controller in a different site. Nobody sees a replication error anywhere. repadmin /showrepl is clean across the board.

Then a domain controller logs Event 2095, and the picture changes: one of the domain controllers in the forest was quietly rolled back to an earlier point in time, and its replication partners have been silently discarding its real, current changes ever since – because as far as they know, they’ve already seen everything it has to say.

What the Error Looks Like

The affected domain controller logs the following in its Directory Service event log, source Microsoft-Windows-ActiveDirectory_DomainService:

Log Name:      Directory Service
Source:        Microsoft-Windows-ActiveDirectory_DomainService
Event ID:      2095
Task Category: Replication
Level:         Error
Description:

During an Active Directory Domain Services replication request, the local
domain controller (DC) identified a remote DC which has received replication
data from the local DC using already-acknowledged USN tracking numbers.

Because the remote DC believes it is has a more up-to-date Active Directory
Domain Services database than the local DC, the remote DC will not apply
future changes to its copy of the Active Directory Domain Services database
or replicate them to its direct and transitive replication partners that
originate from this local DC.

If not resolved immediately, this scenario will result in inconsistencies
in the Active Directory Domain Services databases of this source DC and one
or more direct and transitive replication partners.

The most probable cause of this situation is the improper restore of Active
Directory Domain Services on the local domain controller.

User Actions:
If this situation occurred because of an improper or unintended restore,
forcibly demote the DC.

Nothing shows up as a replication failure before this point. repadmin /showrepl and repadmin /replsummary both report healthy links, because the destination DCs genuinely believe the rolled-back DC’s changes are already accounted for.

What It Actually Means

Every domain controller tracks changes with an update sequence number (USN) – a local counter that increments with every write, whether that write originated locally or arrived through replication. Replication partners track, for each other DC in the forest, the highest USN they’ve already received – the up-to-dateness vector – so they know to ask only for what’s new.

Alongside the USN sits the invocation ID, which identifies a specific instance of a DC’s database. When a domain controller is restored using a supported, Active Directory-aware method, Windows resets the invocation ID and tells every replication partner about it. That reset is the signal partners rely on to know “this DC’s USN counter started over – ask for everything again from here,” rather than assuming the DC is simply behind.

Once that happens, the rolled-back DC keeps issuing new changes using USNs its partners have already marked as seen. Every one of those changes – new accounts, password resets, group membership changes, FSMO role information, DNS records – is silently dropped by every partner, because from their point of view nothing new has arrived. This can persist for days or weeks before anything crosses the threshold that trips Event 2095.

How to Diagnose

Work from the assumption that repadmin /showrepl will look clean – that’s expected, not reassuring. The real evidence is in the Directory Service log and in comparing up-to-dateness vectors directly.

# 1. Check the Directory Service log on every DC for Event 2095
Get-WinEvent -LogName "Directory Service" |
  Where-Object { $_.Id -eq 2095 } |
  Select-Object TimeCreated, Message

# 2. Confirm replication links look healthy from the outside
#    (expected - this will not reveal a rollback by itself)
repadmin /showrepl
repadmin /replsummary

# 3. Compare the up-to-dateness vector the suspect DC has for itself
#    against what a replication partner has recorded for it
repadmin /showutdvec dc1.corp.example.com dc=corp,dc=example,dc=com
repadmin /showutdvec dc2.corp.example.com dc=corp,dc=example,dc=com

# 4. Check for forensic evidence of a rollback quarantine on the
#    suspect DC even if the 2095 event has aged out of the log
Get-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\NTDS\Parameters" -Name "Dsa Not Writable" -ErrorAction SilentlyContinue

The Dsa Not Writable registry entry is set to 0x4 under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters when the rollback-detection code quarantines a DC. Its presence is forensic evidence a rollback occurred even if the triggering Event 2095 has already scrolled out of the log.

Common Causes

Working Through a Fix

There are three supported recovery paths. Which one applies depends on what’s actually available – a valid recent backup changes the answer completely, so check for one before choosing.

If no valid system-state backup exists newer than the rollback, the rolled-back DC cannot be trusted and must be removed from the domain. Force-demote it – this does not attempt to replicate its state anywhere first, so any changes it made after the rollback point that never left it are gone:

# Force-demote the domain controller (minimum required arguments)
Uninstall-ADDSDomainController -ForceRemoval:$true -DemoteOperationMasterRole:$true

# On a healthy DC, clean up the demoted DC's leftover metadata
ntdsutil
metadata cleanup
connections
connect to server dc2.corp.example.com
quit
remove selected server dc1.corp.example.com
quit
quit

If the demoted DC held any FSMO roles, they still need to be moved. Since it’s gone for good, seize rather than transfer:

ntdsutil
roles
connections
connect to server dc2.corp.example.com
quit
seize rid master
q
q

Reinstall Active Directory on the server afterward if it’s going to serve as a domain controller again, and reconfigure global catalog and any operations master roles it previously held.

If a valid system-state backup exists from after the rollback point, restoring it is simpler and avoids the metadata cleanup entirely – an Active Directory-aware system-state restore correctly resets the invocation ID and re-enters replication cleanly.

If no backup exists but the pre-rollback snapshot or disk image is still available, it can be used as a source to force a new invocation ID rather than starting over completely – a narrower recovery path documented for virtualized domain controllers, worth reaching for before defaulting to a full force-demotion when the DC is otherwise intact.

How to Prevent It

The single biggest reduction in risk is running domain controllers only on Windows Server 2012 or later, on a hypervisor that correctly implements VM generation ID – Hyper-V has supported it since Windows Server 2012, and Active Directory uses the ID change to reset its own invocation ID automatically after a snapshot revert. This turns what used to be a silent rollback into a safe, self-healing re-entry into replication.

Beyond that, the rule is procedural: never restore, copy, or revert a domain controller’s system state using anything other than an Active Directory-aware backup and restore tool operating through Microsoft’s supported APIs. Disk imaging tools, raw file copies, and storage-level snapshots taken without an AD-aware wrapper around them are the common thread in every unsupported rollback scenario.

Quick Reference

Final Thoughts

A USN rollback is dangerous precisely because it doesn’t look like a failure while it’s happening. Replication reports green, monitoring stays quiet, and the only symptoms are scattered, hard-to-correlate reports of stale passwords and missing objects – until Event 2095 finally names the problem.

The fix is rarely subtle once you’re there: a DC that went backwards in time without telling anyone almost always has to be removed and its metadata cleaned up, unless a genuinely newer backup exists. The real leverage is upstream of that – modern virtualization platforms with working generation ID support, and a hard rule that Active Directory only ever gets restored through AD-aware tooling.