Active Directory uses two replication models side-by-side. Multi-master replication is the default and covers 99% of directory data — users, groups, computers, OUs, ACLs. Single-master replication covers the five FSMO (Flexible Single Master Operations) roles, where allowing any DC to write would break the forest.
This is Part 2 of the AD Replication Deep Dive series. Part 1 covered the metadata machinery — USNs, HWMV, UTDV. This part explains which changes use that machinery in “everyone can write” mode and which are restricted to one DC at a time.
Multi-master replication
Multi-master means every DC can accept writes for a given naming context. A new user created on DC1 in New York lands on DC2 in Chicago and DC3 in Los Angeles within seconds. Critically, a user created on DC2 in Chicago lands on DC1 just as smoothly — there’s no “primary” node.
What gets multi-mastered
- User and computer accounts (creation, password changes, attribute edits)
- Groups and group membership
- Organizational Units
- Access control lists (ACLs)
- Site links, subnets, and most Sites and Services data
- SYSVOL contents (file replication via DFS-R / FRS sits beside AD but ships with it)
How a multi-master write propagates
- Admin creates user
jdoeon DC1. DC1 commits, bumps its USN, marks the object as an originating write. - DC1 fires a change notification to its replication partners after a 15-second hold (intra-site default).
- DC2 pulls; DC1 ships the new object. DC2 commits the replicated write under its own USN.
- DC3 pulls from DC2 (or DC1, depending on topology). HWMV / UTDV prevent re-shipping.
- Within a few seconds (intra-site) or 15–180 minutes (inter-site), every DC has
jdoe.
What about conflicts?
If two admins edit jdoe’s phone number on two different DCs in the same second, multi-master needs a referee. AD uses a deterministic, three-tier comparison: version number → timestamp → originating-DC GUID. Every DC reaches the same answer independently. The full reconciliation logic is Part 8 of this series — the important thing here is that multi-master tolerates conflicts; it doesn’t prevent them.
Why multi-master matters
- Local writes: Users get fast password changes on whichever DC their site links to.
- Survives DC outage: One DC down doesn’t freeze the directory — writes continue elsewhere.
- Scales geographically: A multi-site forest doesn’t depend on a single “source of truth” node.
Single-master replication: the five FSMO roles
Five operations would create chaos if any DC could perform them concurrently. For these, AD assigns one DC per role — the FSMO role holder. Other DCs receive the changes via normal multi-master replication, but they can’t originate them.
The five FSMO roles
| Role | Scope | What it owns | What breaks if missing |
|---|---|---|---|
| Schema Master | Forest | The schema NC — attribute and class definitions | No schema extensions (Exchange installs, Entra Connect upgrades, AD schema updates) |
| Domain Naming Master | Forest | Adding / removing domains and application partitions | Can’t add or remove a domain in the forest |
| RID Master | Domain | Issues 500-SID blocks (Relative ID pools) to other DCs | DCs eventually run out of RIDs and can’t create new security principals |
| PDC Emulator | Domain | Authoritative time source, password change forwarder, lockout aggregator, GPO last-writer | Password changes feel inconsistent; clocks drift; Group Policy editing conflicts |
| Infrastructure Master | Domain | Updates cross-domain object references (phantom records) | Group memberships referencing foreign-domain users show stale SIDs |
Why these have to be single-master
- Schema Master: Two DCs simultaneously adding an attribute named
employeeBadgeIDwith different OIDs would corrupt the schema permanently. - Domain Naming Master: Two DCs simultaneously adding a domain named
finance.contoso.comcreates a split-brain forest. - RID Master: If two DCs handed out overlapping RID pools, two security principals could end up with the same SID — one of AD’s few unrecoverable failures.
- PDC Emulator: Time hierarchy needs a root; password lockout state needs a single aggregation point.
- Infrastructure Master: Phantom-record updates must happen on one DC to stay consistent.
Locating the role holders
From a command prompt:
netdom query fsmoFrom PowerShell:
Get-ADForest | Select-Object SchemaMaster, DomainNamingMaster
Get-ADDomain | Select-Object PDCEmulator, RIDMaster, InfrastructureMasterMoving roles — transfer vs seize
Two operations: transfer (graceful, both DCs online) and seize (the original holder is dead and never coming back).
Transfer via PowerShell:
Move-ADDirectoryServerOperationMasterRole -Identity DC02 -OperationMasterRole PDCEmulatorSeize via ntdsutil (only when the current holder is permanently lost):
ntdsutil
roles
connections
connect to server DC02
quit
seize PDCNever seize a role if the original holder can be brought back online — bring it back, transfer cleanly, then demote. Seizing leaves stranded metadata that causes lingering-object problems later.
How both models coexist on the same DC
A single DC participates in both models simultaneously. Picture DC1 holding the PDC Emulator role. On the same DC:
- Creating a user — multi-master, originates locally, replicates to peers.
- Receiving that user’s creation from another DC — multi-master, replicated write.
- An admin updating an existing GPO — multi-master, but the PDC Emulator is the recommended editor to avoid edit conflicts.
- A password change — multi-master commit, plus a notification fan-out to the PDC Emulator (so a failed login on any DC can re-check with the PDC before lockout).
- Adding a domain to the forest — single-master, must hit the Domain Naming Master.
Things that bite people
Treating FSMO as a single point of failure
It isn’t, in the short term. Lose the RID Master and existing DCs still have ~500 unused RIDs each — you have hours to fix it. Lose the PDC Emulator and time drifts slowly. The forest doesn’t implode the moment a role holder dies. Plan recovery, don’t panic.
Seizing too aggressively
Production environments seize FSMO roles after a 30-minute outage. Then the original DC comes back, two DCs think they own the role, and metadata cleanup is hours of work. Only seize when the holder is gone permanently (failed hardware, ransomware, lost forever).
Schema changes during a multi-master DC outage
If the Schema Master is offline when Exchange Setup runs its schema extension, you must transfer or seize the role before continuing. The installer will fail with a confusing error otherwise.
Putting all FSMO roles on one DC
Common in small environments — convenient until that DC dies. Two-DC minimum: PDC Emulator + RID Master on DC1, Schema + Naming + Infra on DC2. Domain Naming and Schema should both live on a global catalog when possible.
Infrastructure Master + Global Catalog conflict
In a single-domain forest, the Infrastructure Master’s job is essentially a no-op — put it anywhere. In a multi-domain forest, the Infrastructure Master should not be on a Global Catalog (the GC sees foreign domains directly and the IM logic stops working correctly). Modern forests usually flip every DC to GC, which makes this rule less relevant — but check before flipping.
What’s next
You now know which replication model owns which data. Part 3 in the AD Replication Deep Dive pathway goes one layer deeper: how an object’s metadata is modified during replication — uSNCreated, uSNChanged, version numbers, timestamps, and the replPropertyMetaData attribute that records the originating write for every property.