Chad DuffeySecurity engineer

Active Directory Replication and topology

Replication metadata and conflicts

USNs, invocation IDs, high-watermarks, linked values, and the evidence behind an attribute change.

Local USNs are not a forest clock

Each DC assigns local update sequence numbers to database changes. uSNChanged from DC1 cannot be compared numerically with uSNChanged from DC2 to decide which object is newer. Receiving a replicated change also gives that change a local USN on the receiving DC.

Get-ADRootDSE -Server 'DC1.contoso.com' |
    Select-Object dnsHostName, highestCommittedUSN,
        defaultNamingContext, configurationNamingContext

To compare the change across replicas, use its originating version, invocation ID, USN, and timestamp.

Two filters prevent repeated work

The high-watermark tracks how far a destination has read from a particular source for a naming context. The up-to-dateness vector tracks changes already known from their original writers, including changes received through other DCs. The second filter prevents a change from circulating endlessly around the topology.

repadmin /showrepl DC1 /verbose
repadmin /showutdvec DC1 "DC=contoso,DC=com" /latency

These describe what a particular replica knows about a partition. A vector entry doesn’t mean it has a direct connection to that originator. The replication technical reference explains the distinction.

DSA GUID and invocation ID have different jobs

The DSA object GUID identifies the DC’s NTDS Settings object. The invocation ID identifies an incarnation of its database. A supported restore changes the invocation ID so partners do not mistake restored lower USNs for changes they have already seen.

When investigating a restore or USN rollback, capture both values and the Directory Service events. Do not attempt to repair replication by editing USNs or invocation IDs. Virtualized DC safeguards depend on supported behavior throughout the restore path.

Ask which attribute changed, and where

repadmin /showobjmeta DC1 "CN=Alice,OU=People,DC=contoso,DC=com"
repadmin /showobjmeta DC2 "CN=Alice,OU=People,DC=contoso,DC=com"

Compare the relevant attribute’s version and originating metadata on the two DCs. whenChanged alone is a poor substitute for this comparison.

Get-ADReplicationAttributeMetadata `
    -Object 'CN=Helpdesk,OU=Groups,DC=contoso,DC=com' `
    -Server 'DC1.contoso.com' -ShowAllLinkedValues |
    Select-Object AttributeName, AttributeValue, Version,
        LastOriginatingChangeTime, LastOriginatingChangeDirectoryServerIdentity

Use -ShowAllLinkedValues when investigating individual group membership values. The cmdlet documentation describes the returned metadata. The originating DC and time help narrow the search, but you’ll need audit records to identify who requested the change.

Attribute conflicts and naming conflicts

AD resolves competing updates to an attribute using replication metadata. Higher version wins; timestamps and the originating DSA identity break ties. This is why time accuracy still matters even though USNs drive change tracking.

A naming conflict is different: distinct objects resolve to the same name under the same parent, for example after independent creation before replication connected the changes. One object receives a conflict name containing CNF: and a GUID. Inspect both objects, their dependencies, and their metadata before deciding what to keep. The replication model reference describes the conflict-resolution rules.

Notification is not the data transfer

Change notification asks a partner to replicate sooner. The partner still pulls. Intersite schedules, notifications, and urgent-change behavior produce different delays without changing that model. One password test or one site’s behavior won’t give you a universal replication delay.

Compare the originating stamp, not the local receipt

Use one attribute as the unit of comparison. If DC1 and DC2 show the same version, originating invocation ID, originating USN, and originating timestamp for description, they agree about the originating update even when local USNs or whenChanged differ. If the originating stamps differ, determine whether one replica has not received the update or whether independent writes competed.

$object = 'CN=Alice,OU=People,DC=contoso,DC=com'
foreach ($server in 'DC1.contoso.com','DC2.contoso.com') {
    Get-ADReplicationAttributeMetadata -Object $object -Server $server `
        -Properties description |
        Select-Object @{Name='QueriedDC';Expression={$server}},
            AttributeName, Version, LastOriginatingChangeTime,
            LastOriginatingChangeDirectoryServerInvocationId,
            LastOriginatingChangeUsn, LocalChangeUsn
}

The replication metadata structure distinguishes the originating version/time/identity from the local application sequence number. Keep the raw GUIDs if resolving a retired originator’s name makes the comparison harder to follow.

An up-to-dateness entry has a partition and an incarnation

Suppose DC1 originated a change and DC2 received it through DC3. DC2’s vector can know DC1’s originating update without ever having a direct replication connection from DC1. The high-watermark for DC3 and the vector entry for DC1 therefore answer different questions.

Compare entries only for the same naming context and originating invocation ID. A retired invocation can remain in a vector; its age alone is not proof that a live DC is failing. After restore, distinguish the new invocation from the earlier database’s history. /showutdvec /latency orders vector entries by recency. Its order is not a measured end-to-end delivery time for a new object.

Linked values change the membership investigation

With modern linked-value replication, each group member value has its own metadata. Two DCs can independently add different members and keep both changes. A nonlinked multivalued attribute doesn’t get that behavior just because it holds several values.

When investigating one member, include deleted/deactivated link metadata if needed rather than inspecting only the group’s ordinary attribute stamp:

Get-ADReplicationAttributeMetadata -Object `
    'CN=Helpdesk,OU=Groups,DC=contoso,DC=com' `
    -Server 'DC1.contoso.com' -ShowAllLinkedValues -IncludeDeletedObjects |
    Where-Object AttributeName -eq 'member' |
    Select-Object AttributeValue, Version, LastOriginatingChangeTime,
        LastOriginatingChangeDirectoryServerIdentity

The cmdlet’s linked-value options expose those records. They show directory change history. You’ll need separate checks for the user’s current token, primary group, or access in a resource domain.

Replication carries current state, not every edit

If a single attribute is changed repeatedly before a partner asks for updates, that partner can receive the resulting current value and originating stamp without receiving every intermediate application value. Replication metadata is not a transaction audit trail. Recovering an earlier value requires the relevant audit history, backup, or other retained evidence.

A workflow that changes several objects isn’t a distributed transaction either. A destination can see one object’s update before the rest arrives, while another DC accepts a conflicting write. Applications have to cope with those intermediate states. The AD system overview describes partition-specific replication and eventual convergence. A successful local LDAP modification doesn’t make the whole workflow atomic across replicas.

The source’s up-to-dateness vector is transferred when a replication cycle completes. Receiving one object’s value is therefore a narrower observation than completing the whole source cycle. When a partial initial cycle is interrupted, capture both object-level evidence and partner/vector state. Microsoft’s replication-filtering explanation describes the high-watermark/vector roles.

LostAndFound is a parent conflict

If one DC creates or moves a child while another removes its parent, the surviving child can be placed under the naming context’s LostAndFound container. That is distinct from two objects competing for the same RDN (CNF) and from a lingering object whose deletion history was missed. The AD technical glossary defines this container.

For the domain NC, inspect its immediate children on an explicit replica:

$dc = 'DC1.contoso.com'
$nc = (Get-ADRootDSE -Server $dc).defaultNamingContext
Get-ADObject -Server $dc -SearchBase "CN=LostAndFound,$nc" `
    -SearchScope OneLevel -LDAPFilter '(objectClass=*)' `
    -Properties objectGUID,whenCreated,whenChanged |
    Select-Object DistinguishedName,objectGUID,whenCreated,whenChanged

Compare the object GUID and parent/delete history across replicas before moving or deleting anything. Moving a security principal to another OU can change its policy scope and delegated administration. An empty result only tells you this container was empty in this DC’s readable view; naming conflicts may still exist elsewhere.

← All Active Directory topics