Multi-master replication doesn’t prevent conflicts — it tolerates them. Two admins on two DCs can simultaneously edit the same attribute, create the same object, or move and delete things at cross purposes. AD picks a winner deterministically so every DC reaches the same final state, no admin coin-flip needed.
This is Part 8 of the AD Replication Deep Dive series. We walk every conflict class AD knows about, the rule chain it uses to resolve each, and the cases where AD doesn’t resolve and an admin has to.
The universal three-step tie-breaker
For most conflicts AD uses the same comparison ladder. Compare in order, stop at the first column where the two changes differ:
- Version number. Higher wins.
- Timestamp. Later wins.
- Originating-DC GUID. Numerically higher wins.
The tie-breaker is deterministic precisely because GUIDs are guaranteed unique — you never reach step 3 without a unique answer.
Conflict class 1: identical attribute change
Same attribute on the same object updated on two DCs at roughly the same time. Example: admin on DC1 changes telephoneNumber on user jdoe at 10:00. A different admin on DC2 changes the same attribute on the same user at 10:00:05.
Each DC stamps its write with version, timestamp, originating-DC GUID. When the two writes meet (via replication on a third DC, or when the two source DCs sync), every DC runs the three-step compare:
- Both writes are version 2 (the previous value was version 1). Tie.
- DC2’s timestamp (10:00:05) is later than DC1’s (10:00:00). DC2 wins.
- GUIDs irrelevant.
Outcome: jdoe.telephoneNumber ends up at DC2’s value, everywhere. DC1’s write is discarded silently — no admin notification. This is the “last writer wins” behaviour most other directories also use.
Conflict class 2: object created under a now-deleted parent
Different scenario: admin on DC1 creates user asmith under OU=People. At nearly the same time, a different admin on DC2 deletes OU=People. When the changes meet, what happens to asmith?
Outcome: the parent stays deleted, the child is moved to CN=LostAndFound — a special container at the root of every domain NC for exactly this case (full DN: cn=LostAndFound,dc=mycorp,dc=com).
The orphaned object is preserved with all attributes intact; only its location moves. An admin can inspect LostAndFound periodically (or set up monitoring), see the stranded object, and either delete it or move it to a real OU.
Conflict class 3: duplicate RDN
Two admins each create an object with the same relative distinguished name (RDN, the leftmost CN= or OU= component) in the same container, on different DCs. Example: DC1 creates CN=PC04,CN=Computers,DC=contoso,DC=com; DC2 creates a different computer also named CN=PC04 at the same path.
Each is internally a brand-new object with its own object GUID. When replication catches them, AD applies the three-step comparison on the objects themselves (not on attributes):
- Version — both objects are version 1 (newly created). Tie.
- Timestamp — later creation wins.
- If timestamps still equal: higher originating-DC GUID wins.
The loser is not deleted. AD renames it with a CNF (conflict) suffix:
CN=PC04\0ACNF:41968ad2-717e-4ffc-a876-04798d288ede,CN=Computers,DC=contoso,DC=comThe \0A is the literal byte 0x0A (line-feed) as a separator, followed by CNF: and the loser’s object GUID. Two consequences:
- The winner has the clean name (
CN=PC04) and is the “real” object. - The loser still exists with all its data, under a name no one will type accidentally. An admin can audit, recover its data, or delete it.
Special case: duplicate sAMAccountName
The RDN-conflict logic only renames the CN. For accounts that means login attributes (sAMAccountName, userPrincipalName) might still collide — you’d have two users with username asmith after a CNF rename.
AD handles this separately. The newest sAMAccountName wins as-is. The losers get rewritten to $DUPLICATE-<RID>, where <RID> is the relative ID portion of the object’s SID. The objects continue to exist, but with placeholder login names that won’t authenticate until an admin renames them.
Special case: duplicate SID
SIDs are supposed to be unique by construction (the RID Master hands out non-overlapping pools). They can collide after a USN rollback, a botched backup restore, or RID-pool corruption. AD’s response is uncompromising: delete every object holding the duplicate SID.
This sounds drastic but is correct — a duplicate SID is a security hole. Two principals with the same SID get the same access rights everywhere. AD treats it as “impossible state, must purge.” You then re-create the affected user(s) from scratch with a fresh SID.
How the resolution replicates
The reconciliation isn’t done by one DC and broadcast. Every DC computes the same answer independently. When DC3 sees the conflicting changes from DC1 and DC2, it runs version → timestamp → GUID and decides DC2 wins. When DC1 later replicates from DC3 and sees DC2’s winning version, DC1 runs the same logic against its local copy, agrees that DC2 wins, and updates itself accordingly.
This independent-agreement property is why AD doesn’t need a quorum or a leader for conflict resolution. Any subset of DCs can be online and partitioned and still reach the same answer when they reconnect.
Worked example: three DCs, one user, two edits
Three DCs: A, B, C. They’re all in sync. User john currently has displayName = "John Smith", attribute version 1, originated on A long ago.
- Admin on DC-B edits
displayName = "John Smith"→"John A. Smith"at 09:00:00. Version 2, originating DC = B. - Different admin on DC-C edits
displayName = "John Smith"→"J. Smith"at 09:00:07. Version 2, originating DC = C. - DC-A pulls from DC-B first. Accepts the change (no conflict yet — A still has version 1). A now has B’s value, version 2, originating DC = B, timestamp 09:00:00.
- DC-A then pulls from DC-C. Sees C’s version-2 write for the same attribute. Conflict. Three-step compare: versions equal (both 2). Timestamps: C’s 09:00:07 > B’s 09:00:00. C wins.
- DC-A updates
displayNameto"J. Smith", version still 2 (it’s the same logical attribute write), originating DC = C, timestamp 09:00:07. - DC-B later pulls from DC-A and runs the same comparison: B’s own write vs C’s. Same outcome. DC-B overwrites its own value with C’s.
Final state across all DCs: displayName = "J. Smith", version 2, originating DC = C. B’s write is forever lost. The admin who made the “John A. Smith” change has no AD-side indication their edit was overwritten — they’d have to compare audit logs to find out.
The crashed-DC scenario
Admin makes 20 changes on DC-D. Before replication fires, DC-D crashes. Two outcomes:
- DC-D never returns. All 20 changes are lost. No DC has them. AD has no way to know they existed.
- DC-D returns much later. The forest has since had its own edits to the same objects. DC-D’s changes try to replicate out, but most lose the version/timestamp comparison to the forest’s newer state. Most of DC-D’s offline writes are silently overwritten.
This is normal behaviour, not a bug. Multi-master replication assumes recency over precedence — if your DC was offline while everyone else moved on, your version of reality loses.
Things that bite people
Lost writes are silent
There’s no event log, no notification, no admin tool that says “your change was lost in a replication conflict.” The only forensic evidence is in replPropertyMetaData — if the originating DC for the current value isn’t yours, your write lost.
CNF objects pile up unnoticed
Conflict-renamed objects with \0ACNF: in the CN look weird but won’t throw alerts. Audit periodically:
Get-ADObject -LDAPFilter "(cn=*\0ACNF:*)" -SearchScope SubtreeAnd clean them up after deciding whether to merge or discard.
LostAndFound is invisible by default
The CN=LostAndFound container is hidden in ADUC unless you turn on Advanced Features. Orphaned objects can sit there for years. Set a scheduled task to scan and email any contents.
Clock skew distorts “later wins”
If DC2’s clock is 2 minutes ahead of DC1’s, DC2’s writes always win the timestamp tiebreaker even when they happened “first” in real time. Tight NTP discipline is the real defence here.
USN rollback after snapshot revert
If a DC’s invocation ID doesn’t rotate during a revert (older Windows or Hyper-V), it ends up issuing “new” writes with USNs the forest has already seen. The forest considers them duplicates, ignores them — this is a special case of the silent-loss problem and explains why USN rollback quarantine is so aggressive.
What’s next
Conflict resolution handles writes that meet in motion. There’s another class of failure where the meeting never happens because a DC is offline too long: lingering objects. Part 9 of the AD Replication Deep Dive pathway explains the tombstone lifetime, how a long-offline DC reintroduces ghosts of deleted objects, and how to detect and purge them.