Active Directory replication is the engine that keeps every domain controller’s copy of the directory in agreement. It’s also where most “weird” AD problems live — lingering objects, USN rollback, stale group memberships — and you can’t debug any of them without first understanding how the replication state machine actually works.
This is Part 1 of a 10-post deep dive into AD replication. We start at the bottom layer: USNs, DSA GUIDs, invocation IDs, the high-watermark vector, and the up-to-dateness vector. These five concepts are the entire vocabulary the rest of the series uses.
Why replication is metadata-driven, not time-driven
You might assume AD replication compares timestamps to decide what to ship. It doesn’t. Time is too unreliable across nodes — clock drift, DST jumps, or a VM rolled back to a snapshot all break time-based reasoning. Microsoft chose a monotonically-increasing counter instead, called the Update Sequence Number (USN).
Time still matters for one thing: Kerberos authentication. If two DCs disagree on the time by more than five minutes, the Kerberos tickets they exchange won’t validate and replication can’t even start. But once authenticated, every replication decision is made with USNs and GUIDs, not clocks.
Update Sequence Numbers (USNs)
Every change committed to a DC’s copy of the directory bumps that DC’s local USN by one. A USN is a 64-bit counter, scoped to that DC. The highestCommittedUSN attribute on RootDSE tells you the current top of that counter.
Three rules to remember:
- USNs only ever go up — never reset, never reused, even if a transaction aborts.
- USNs are only meaningful on the DC that issued them. The same logical change has a totally different USN on every DC.
- USNs going backward — the classic snapshot-revert symptom — trigger USN rollback, which AD treats as a critical failure and refuses to replicate.
Example: you create five users on DC A. DC A’s USN advances by 5 — each one is an originating write. Those changes replicate to DC B, advancing DC B’s USN by 5 — replicated writes. Later DC A pulls one change from DC B; DC A’s USN advances by 1. The numbers don’t match across DCs because they were never supposed to.
Two GUIDs every DC carries: DSA GUID and Invocation ID
Each DC has two distinct identifiers, and confusing them costs hours during disaster recovery.
- DSA GUID — the object GUID of the NTDS Settings object under the DC in Sites and Services. Identifies the DC itself. Only changes if you demote and re-promote.
- Invocation ID — the GUID of this particular copy of
ntds.dit. Stored in theinvocationIdattribute. Changes when AD is restored from backup, when the DSA GUID changes, or when Windows Server 2012+ detects a new VM Generation ID after a snapshot revert.
The invocation ID is the safety net against USN rollback. When a DC is restored, its USN counter jumps back to wherever the backup left off — but the rest of the forest has already processed updates past that point. If the invocation ID didn’t change, peers would assume “this DC has USN 1,000, we’ve already sent it everything up to 1,500” and never re-send the missing 500. Rotating the invocation ID tells every peer: this is effectively a brand-new database; rebuild your HWMV and UTDV entries for it from scratch.
ntds.dit and resets after a restore or VM Gen ID change.The High-Watermark Vector (HWMV)
Each DC keeps one HWMV table per naming context per partner. Each row stores: “the highest USN I’ve received from this specific partner for this specific NC.”
When DC A pulls from DC B, DC A says: “Last time I asked you for the Domain NC, I got up to your USN 1,108. Send me anything past that.” DC B compares to its own highestCommittedUSN for that NC, finds 1,112, and ships USNs 1,109–1,112.
The HWMV is what makes replication incremental — without it, every cycle would re-ship the entire NC.
The Up-To-Dateness Vector (UTDV)
The HWMV alone can’t prevent loops. Picture three DCs in a triangle: DC A creates an object, DC B pulls it from A, DC C pulls it from A. Now DC B pulls from DC C — without extra metadata, DC C would re-ship A’s update that DC B already has. Multiply that across hundreds of DCs and you get a replication storm.
The UTDV solves it. Each DC keeps one UTDV per NC, with one row per originating DC ever seen in the forest. The row stores: “the highest originating USN I’ve ever applied that came from this DC, regardless of who shipped it to me.”
When DC A requests changes from DC B, it sends its UTDV along with the HWMV cursor. DC B uses the UTDV to filter out updates that originated on DCs whose updates A has already seen via someone else. This is propagation dampening, and it’s the reason AD replication doesn’t flood the network.
A complete example: three DCs, one change
Walk through what happens when an admin creates one user on DC A in a 3-DC forest:
- DC A commits the new user. DC A’s USN goes 1,000 → 1,001. The user’s
uSNCreatedanduSNChanged= 1,001.replPropertyMetaDatafor every attribute carries Origin-DSA=A, Origin-USN=1,001, Version=1. - Intra-site notification fires after a 15-second hold (configurable). DC A tells DC B and DC C “I have something new.”
- DC B pulls. Sends its HWMV (“last from A was 1,000”) plus its UTDV. DC A ships USN 1,001. DC B applies it under its own next USN (say 2,500). The user’s
uSNChangedon DC B is 2,500, butreplPropertyMetaDatastill says Origin-DSA=A, Origin-USN=1,001. - DC C does the same, gets USN 3,777 locally.
- Later DC C pulls from DC B. DC B looks at DC C’s UTDV, sees DC C is already at Origin-USN 1,001 from DC A. Skips. No duplicate send.
Things that bite people
Snapshot reverts on virtualised DCs
Reverting a DC VM to a snapshot rewinds its USN. On Windows Server 2012+ the VM Generation ID changes, triggers an invocation ID rotation, and AD survives. On older OSes, or if the hypervisor doesn’t expose Gen ID, you get USN rollback — the DC quarantines its own NTDS service and the only recovery is demote + clean metadata + re-promote.
USN values aren’t comparable across DCs
Don’t troubleshoot by spotting that DC A is at USN 50,000 and DC B is at USN 200,000 and concluding B is “ahead.” They’re different counters. Use repadmin /showrepl or repadmin /replsummary to see actual replication state.
Backup older than tombstone lifetime
Restoring an AD backup older than the tombstone lifetime (60 or 180 days) reintroduces objects the rest of the forest deleted long ago. The HWMV/UTDV machinery can’t catch this on its own — that’s the lingering-object problem (Part 9 of this series).
Clock skew breaks replication before it starts
5-minute Kerberos tolerance. NTP misconfigured on one DC, replication errors look bizarre (handshake fails, not data fails). Always check time first when a DC stops replicating.
What’s next
You now have the vocabulary — USN, originating vs replicated write, DSA GUID, invocation ID, HWMV, UTDV. Part 2 in the AD Replication Deep Dive pathway uses these to compare AD’s two replication models: multi-master (the default, for almost all directory data) and single-master (for the five FSMO roles).