An Active Directory replication up-to-dateness vector (UTD vector or UTDVEC) records, for one naming context, the highest originating update sequence number (USN) that a domain controller has applied from each originating directory-database identity. In plain English, it answers: “For each database identity, what is the latest originating change this replica knows it has applied?”
That makes the vector valuable for investigating replication latency, missing updates, restores, and database divergence—but it is not a single replication-health score. It is partition-specific, depends on invocation IDs, and must be read alongside replication status, event logs, topology, and object-level metadata.
As an Amazon Associate I earn from qualifying purchases.
How Active Directory tracks replicated changes
Active Directory Domain Services (AD DS) does not simply copy an entire directory database between domain controllers. Domain controllers exchange changes and use replication metadata to avoid repeatedly requesting or sending updates that are already represented on the destination.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsSeveral types of metadata work together:
| Metadata | What it identifies or records | Scope |
|---|---|---|
| Originating USN | The sequence number assigned when a change is made in an originating directory database | One database identity |
| Invocation ID | The logical replication identity of a particular instance of a DC’s directory database | Database history |
| UTD vector | The highest originating USN applied from each invocation ID | One replica and naming context; includes transitive history |
| High-watermark table | The latest changes received directly from a particular source DC | One direct source-to-destination relationship |
| Object replication metadata | Attribute versions, originating times, invocation IDs, and originating USNs | Individual objects and attributes |
Microsoft’s protocol definition of the up-to-dateness vector describes entries using an invocation ID, a highest applied USN, and a time associated with successful synchronization or latency reporting.
#1 Best Overall
- Dell PowerEdge R730xd 24B SFF 2U Server
- 2x Intel Xeon E5-2690 v4 2.6Ghz 14-Core (28-cores Total)
- 128GB DDR4 RAM – 4x 1.2TB 10K SAS 2.5” 12Gb/s
- Dell H730P mini 2GB 12Gb/s RAID
- 2x 750W PSU - 2x 10Gb SFP+ 2x 1Gb (RJ45) NIC
What is an originating USN?
A USN is local to the directory database that generated it. The same number on two domain controllers does not identify the same change.
- USNs are meaningful only together with the originating invocation ID.
- A local USN sequence is not a forest-wide clock.
- Local changes can advance a DC’s sequence independently of other DCs.
- Comparing raw USN numbers across different DCs is unsafe.
For example, USN 42,000 from DC1 does not inherently have a relationship to USN 42,000 from DC2. The invocation ID supplies the database identity needed to interpret the number. Microsoft’s PowerShell documentation also notes that an object’s replicated USN is local to each domain controller and can differ between DCs.
Invocation ID versus DSA object GUID
A domain controller has several identities that administrators commonly see in replication output:
- Server or DNS name: The human-readable network name, such as
DC1. - DSA object GUID: The GUID identifying the domain controller’s directory service agent object in Active Directory topology.
- DSA invocation ID: The logical identity of the current instance of that DC’s directory database for replication purposes.
A typical repadmin /showrepl result includes:
DSA object GUID: 966651f3-a544-461f-9f2c-c30c91d17818
DSA invocationID: b0d9208b-8eb6-4205-863d-d50801b325a9When matching a GUID-based UTD-vector entry, use the invocation ID, not merely the server name or DSA object GUID.
An invocation ID can change after a supported restore or another database-identity event. This allows replication partners to treat the restored database history as a new source identity. A new invocation ID is therefore not, by itself, proof of data loss or corruption. See Microsoft’s virtualized domain controller guidance.
What a UTD-vector entry means
A representative entry might look like this:
DC1 @ USN 42000 @ Time 2026-08-16 14:35:22It means that the inspected replica records the highest applicable originating USN from the invocation ID associated with DC1 as 42,000.
- DC1: A cached, translated name for an invocation ID.
- USN 42000: The highest originating USN from that identity that the replica considers applied.
- Time: A synchronization or latency-related time associated with the vector entry—not necessarily the exact time every represented change was created or modified.
With name caching disabled, the output uses the GUID:
3e04086d-da99-465f-b82d-e74f31a1caf1 @ USN 42000 @ Time 2026-08-16 14:35:22Use /nocache when you need an unambiguous identity and match the GUID to DSA invocationID in repadmin /showrepl.
How the vector enables transitive replication
Suppose DC1 originates a user change. DC2 receives it directly. Later, DC3 receives the same change from DC2 rather than directly from DC1. Because the change retains its originating metadata, DC3 can record DC1’s invocation ID and originating USN in its own UTD vector.
| Originating identity | Highest originating USN applied by DC2 |
|---|---|
| DC1 invocation ID | 42,000 |
| DC2 invocation ID | 18,500 |
| DC3 invocation ID | 31,700 |
DC2’s DC1 entry does not prove that every update through USN 42,000 arrived directly from DC1. It means DC2 believes it has applied eligible originating updates from that identity through that point. The entry may include changes received through another replication path.
This transitive history helps a source avoid sending updates whose originating changes the destination already knows about. The UTD vector is maintained separately for each naming context, so the state for the domain partition does not prove the state for the Configuration, Schema, or an application partition.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallUTD vector versus high-watermark table
This is the distinction most often lost in simplified explanations:
| Question | UTD vector | High-watermark table |
|---|---|---|
| What does it track? | Highest originating USN applied from each database identity | Most recent changes received directly from a source DC |
| Does it include indirect history? | Yes, it can represent transitive-originating updates | No; it describes a direct source relationship |
| Typical use | Determine which originating history a replica knows | Determine what was received from a particular direct partner |
| Level of detail | Partition-level replication history | Source-to-destination replication state |
Neither table alone explains why a particular attribute value won a conflict. For that, inspect object metadata with repadmin /showobjmeta.
Which naming context are you inspecting?
Always identify the affected partition before interpreting a vector:
- Domain:
DC=contoso,DC=com - Configuration:
CN=Configuration,DC=contoso,DC=com - Schema:
CN=Schema,CN=Configuration,DC=contoso,DC=com - Application: An application-specific naming context
- Global Catalog domain replica: A partial, read-only copy of a domain partition
A DC can appear current for one partition while another partition has replication errors. A Global Catalog’s partial replica must also be interpreted differently from a writable domain partition.
Rank #2
- Renewed server with the highest quality standards
- Ideal for a robust enterprise environment or data center
- All servers include power cords, and other parts detailed in full product description below
- Custom configurations available upon request
Inspecting UTD vectors with Repadmin
Run these commands from a domain controller or an administrative workstation with the required AD tools.
Show a vector for a domain partition
repadmin /showutdvec DC1 "DC=contoso,DC=com"Display GUIDs instead of cached names:
repadmin /showutdvec DC1 "DC=contoso,DC=com" /nocacheOrder entries from least current to most current for latency analysis:
repadmin /showutdvec DC1 "DC=contoso,DC=com" /latencyInspect other standard partitions:
repadmin /showutdvec DC1 "CN=Configuration,DC=contoso,DC=com"
repadmin /showutdvec DC1 "CN=Schema,CN=Configuration,DC=contoso,DC=com"The showutdvec syntax page is hosted in Microsoft’s previous-versions documentation, but its conceptual explanation remains useful; do not read it as a statement about a particular current Windows Server build.
Map vector GUIDs to replication identities
repadmin /showrepl DC1Find DSA invocationID in the result and match it to the GUID shown by /nocache. Do not rely on a cached name when investigating a restore or identity change.
Recommended Free Tools
Inspecting vectors with PowerShell
The Active Directory PowerShell module provides a structured view:
Get-ADReplicationUpToDatenessVectorTable -Target DC1Query several DCs:
Get-ADReplicationUpToDatenessVectorTable -Target DC1,DC2,DC3Specify a partition:
Get-ADReplicationUpToDatenessVectorTable `
-Target DC1 `
-Partition "DC=contoso,DC=com"For a broad comparison:
Get-ADReplicationUpToDatenessVectorTable * |
Sort-Object Partner, Server |
Format-Table Partner, Server, UsnFilterPowerShell and Repadmin expose related UTD information, but their parameters, output formats, and presentation differ. Do not assume that identically named columns are a complete one-to-one representation of every internal replication structure.
Check replication health before interpreting the numbers
Start with broad status checks:
repadmin /replsummary
repadmin /showrepl *Export a multi-DC report:
repadmin /showrepl * /csv > showrepl.csvReview DNS, RPC, firewall, authentication, site links, schedules, and Directory Service event logs. A vector comparison collected at different times can produce a misleading picture, especially while replication is actively progressing.
How to interpret common results
A lower USN on one DC
This does not automatically indicate USN rollback. First confirm:
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →- The same naming context was queried.
- The same originating invocation ID is being compared.
- The source and destination roles are correctly identified.
- The outputs were collected close together in time.
- Replication status and events support the conclusion.
Normal causes include an unopened site-link schedule, an incomplete outbound cycle, different replication paths, or DNS/RPC/connectivity problems.
A missing invocation ID
A missing entry is a clue, not a diagnosis. Possible explanations include a newly promoted DC, a source whose database received a new invocation ID after a supported restore, an unexchanged replication path, a different partition, retired historical metadata, or stale metadata after a failed demotion or recovery.
A retired entry
Retired invocation IDs can remain as historical records after a database identity changes. They are not automatically evidence of corruption. Investigate whether an active DC is unexpectedly using an old identity and whether partners have contradictory histories.
The timestamp appears old
The vector timestamp provides synchronization or latency context. It is not necessarily the creation time of a specific object change or the exact timestamp of every USN represented by the entry.
Free tools Windows power users keep installed
One-click scans. No signup required.
Object-level investigation
When a user, computer, group, or attribute is inconsistent, inspect the object directly:
repadmin /showobjmeta DC1 "CN=User1,OU=Users,DC=contoso,DC=com"Object metadata can help answer which DC originated the current value, which attribute version won, and whether the object is present or absent on different replicas. A UTD vector describes partition-level history; it cannot by itself explain every object-level conflict.
Distinguishing latency, rollback, and lingering objects
Normal replication latency
Latency is plausible when the replication schedule, site topology, source outbound cycle, or network path explains the difference. Validate it with showrepl, event timestamps, and repeated observations rather than treating one snapshot as proof.
Rank #3
- Dell 13th Generation Rack Mount 1U 8-Bay 2.5" SFF Server
- Enterprise Server For Home Use
- 2x Intel Xeon Processor E5-2690 v4 2.60GHz 14-Core CPUs
- 128GB PC4-2133 DDR4 Memory
- 2x 1TB 2.5" SATA SSDs - Solid State Drives -
USN rollback
USN rollback can occur when a DC database is reverted to an earlier state without AD DS correctly recognizing the new history. The DC may reuse USNs that partners have already processed. Partners can then believe they have already received changes and fail to request them, producing silent divergence across directory partitions.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Event ID 2095 is commonly associated with detection of USN rollback. Microsoft explains detection and recovery in its USN rollback guidance.
Lingering objects
A lingering object is an object left on one DC after it should have been deleted elsewhere, commonly because the DC was disconnected longer than the forest’s tombstone lifetime or because replication history became inconsistent. Symptoms can include Events 1388 or 1988, blocked replication, deleted objects reappearing, object-creation conflicts, and error 8606.
Event ID 2042 indicates that a DC has not replicated within the tombstone lifetime. Microsoft’s lingering-object guidance recommends preventing excessive disconnection and using documented cleanup tools.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.VMs, snapshots, and restoration
On virtualization platforms that support VM-GenerationID, supported AD DS behavior can detect certain snapshot or rollback conditions and reset the invocation ID. Microsoft describes VM-GenerationID and msDS-GenerationID as protections against replication problems caused by inappropriate rollback.
This does not make arbitrary snapshots, cloning, or copied virtual disks a general-purpose AD backup method. Distinguish among:
- Supported VM-GenerationID-aware recovery.
- System State backup and supported authoritative or non-authoritative restoration.
- Unsupported copying or reverting of a domain controller.
- Restoring a DC while it is isolated from replication partners.
For suspected rollback, common recovery paths documented by Microsoft include demoting and rebuilding the affected DC, with metadata cleanup where necessary, or restoring it from a valid System State backup. The correct choice depends on FSMO roles, Global Catalog status, available backups, the DC’s importance, and the extent of divergence.
Do not manually edit USNs, casually delete replication metadata, or force synchronization before understanding the failure.
Documented lingering-object cleanup
Preserve evidence and confirm the healthy source before any destructive cleanup. In advisory mode:
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →repadmin /removelingeringobjects <DestDC> <GoodSourceDCGUID> "<NamingContext>" /advisory_modeExample:
repadmin /removelingeringobjects DC5 8e294159-140d-41f8-b041-23896e86cb00 "DC=contoso,DC=com" /advisory_modeThe source GUID must identify a healthy, writable replica of the affected naming context. Advisory mode should be used first. For a Global Catalog’s affected read-only domain partition, documented repadmin /rehost procedures may be appropriate:
repadmin /rehost <GC> "<ReadOnlyNamingContext>" <GoodWritableDC>Use the Microsoft Event 1388/1988 guidance and error 8606 guidance for the scenario-specific procedure.
A safe diagnostic workflow
- Identify the naming context: domain, Configuration, Schema, application, or Global Catalog read-only partition.
- Identify source and destination DCs.
- Capture broad health:
repadmin /replsummaryandrepadmin /showrepl *. - Record identities: DSA object GUID and DSA invocation ID from
repadmin /showrepl. - Inspect the destination:
repadmin /showutdvec <DestinationDC> "<NamingContext>" /nocache /latency. - Inspect the source’s corresponding identity and vector.
- Compare the same invocation ID, not just the numeric USN.
- Check Directory Service events: especially 1388, 1988, 2042, and 2095.
- Inspect the object: use
repadmin /showobjmetawhen a particular object or attribute is involved. - Classify the problem: latency, connectivity, topology, rollback, lingering objects, or an object-level conflict.
- Choose recovery only after preserving evidence and identifying the authoritative data.
Evidence to capture before remediation
repadmin /replsummary > replsummary.txt
repadmin /showrepl * /csv > showrepl.csv
repadmin /showutdvec <DC> "<NamingContext>" /nocache > utdvec.txt
repadmin /showobjmeta <DC> "<ObjectDN>" > objectmeta.txtAlso record DC names and addresses, the naming context, both GUID types, event IDs and timestamps, last successful inbound and outbound replication, recent restore or virtualization activity, FSMO roles, Global Catalog status, and DNS/RPC results.
What a UTD vector cannot prove
- That every replication neighbor is reachable.
- That DNS, RPC, authentication, or site topology is correct.
- That every naming context is current.
- That the latest attribute value is correct.
- That no lingering objects exist.
- That the DC is not affected by silent USN rollback.
Similarly, repadmin /syncall initiates synchronization; it does not repair rollback, lingering objects, DNS, authentication, topology, divergent authoritative data, or a database that should be rebuilt.
Recommended Free Tools
Quick reference
| Need to know | Use |
|---|---|
| Overall replication failures | repadmin /replsummary |
| Partners, GUIDs, and last attempts | repadmin /showrepl <DC> |
| UTD state for a partition | repadmin /showutdvec <DC> "<NamingContext>" |
| Uncached GUIDs and latency ordering | /nocache /latency |
| Structured UTD data | Get-ADReplicationUpToDatenessVectorTable |
| Object or attribute history | repadmin /showobjmeta |
| Event | Typical significance |
|---|---|
| 1388 | Lingering object detected and replicated or attempted |
| 1988 | Lingering object detected; replication is blocked or prevented |
| 2042 | Replication interval exceeds the tombstone lifetime |
| 2095 | Often associated with USN rollback detection |
Native Microsoft tools are sufficient for UTD-vector analysis. Commercial assessment, monitoring, or recovery platforms become relevant when an organization needs continuous monitoring, automated recovery workflows, forest-level resilience, incident response, or vendor-supported assessment—not for a one-off inspection that repadmin and PowerShell can perform.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
