Active Directory — Part 7 — Active Directory Replication

Introduction

In Part 3, we established that one Domain Controller is never enough, and that a healthy environment runs several. That raises a question we quietly stepped over at the time.

You change your password at head office. Twenty minutes later you sign in at a branch office, and a completely different Domain Controller authenticates you — with the new password. How did it know?

The answer is Active Directory replication, the background process that keeps every Domain Controller’s copy of the directory converging on the same data. When it works, nobody thinks about it. When it breaks, the symptoms appear everywhere except the place the problem actually lives.

What Is Replication?

Active Directory uses multi-master replication. Every Domain Controller holds a full, writable copy of its domain’s database. A change — a new user, a password reset, a group membership edit — can be written on any DC, and replication carries that change to all the others.

Two design choices matter here. First, replication is pull-based: a DC with changes notifies its partners, but each partner requests the changes itself. Nothing is pushed onto a DC. Second, replication works at the attribute level. If you change a user’s phone number, only that attribute travels across the network, not the whole user object.

The Branch Ledger Analogy

Think of Domain Controllers like branch offices of an old-fashioned bank, each keeping a full copy of the same customer ledger.

Any branch can record a transaction in its own copy. At regular intervals, each branch calls its neighbouring branch and asks: what has changed in your ledger since entry number 4,502? The neighbour reads out only the new entries, and the caller copies them in.

No branch is “the master ledger”. Every copy is authoritative, and the system relies on every branch diligently exchanging updates. If one branch’s phone line goes down for a week, its ledger quietly falls behind — and customers served by that branch start seeing stale information.

What Actually Replicates

The directory database is divided into partitions (also called naming contexts), and each partition replicates to a different audience.

Step 1: A Change Gets a Number

Every Domain Controller keeps a counter called the Update Sequence Number, or USN. Each time anything is written to that DC’s database, the counter increments and the change is stamped with it.

USNs are local. DC1 being at USN 5,000,000 and DC2 at 7,000,000 means nothing by itself — what matters is that each DC remembers the highest USN it has already received from each partner. That bookmark is called the high-watermark, and it is what makes the “what changed since entry 4,502?” conversation possible.

Step 2: Partners Are Notified

Within a site, a DC that has changes waits roughly 15 seconds, then notifies its first replication partner, with a few seconds between notifications to each additional partner. This is why a password reset reaches every DC in the same office within seconds to a minute.

Urgent events — an account lockout, for example — skip the wait and trigger immediate replication, because making users wait on security-critical changes would be dangerous.

Step 3: The Partner Pulls the Changes

The notified partner requests everything above its high-watermark for that partition. The source DC sends only those attribute-level changes, and the partner applies them to its own database — which increments its own USN counter, and the cycle continues outward.

Step 4: Propagation Dampening

In a ring of Domain Controllers, the same change could arrive at a DC from two directions. To avoid replicating data it already has, each DC also tracks an up-to-dateness vector — a summary of the latest originating change it has seen from every DC in the forest. If a partner offers a change the DC already received via another path, it declines. This is called propagation dampening.

The Flow at a Glance

[DC1]  ─── password reset written, USN 4503 ──── (local write)
[DC1]  ─── change notification (~15s later) ───▶ [DC2]
[DC2]  ─── "send changes above USN 4502" ──────▶ [DC1]
[DC1]  ─── attribute-level changes ────────────▶ [DC2]
[DC2]  ─── notification ───────────────────────▶ [DC3]
[DC3]  ─── pull, apply, and so on around the ring

The KCC: Who Replicates With Whom

You do not design the replication topology by hand. A built-in process on every DC called the Knowledge Consistency Checker, or KCC, does it automatically.

Inside a site, the KCC arranges DCs into a bidirectional ring and adds shortcut connections so that no DC is ever more than three hops from any other. When a DC is added or removed, the KCC recalculates the ring on its own.

What If Two DCs Change the Same Thing?

Multi-master means conflicts are possible: two administrators can edit the same attribute on two different DCs in the same window. AD resolves this without human input.

Conflict resolution happens per attribute. The change with the higher version number wins; if the versions match, the later timestamp wins; in the astronomically rare case both match, the change from the DC with the higher invocation ID wins. The losing change is simply discarded — silently.

Sites: Teaching AD Your Network Shape

Everything so far assumed DCs on a fast LAN. Real companies have a head office, branch offices, and WAN links of varying quality between them. Active Directory models this with sites.

A site is a group of well-connected IP subnets — in practice, one physical location. You define your subnets in AD and assign each to a site, and AD then uses that map for two things:

Replication control — traffic inside a site flows freely; traffic between sites is scheduled, compressed, and routed. And client affinity — a workstation in the Mangalore office authenticates against a Mangalore DC rather than one in Mumbai, because the DC locator uses the client’s subnet to find the nearest site.

Intra-Site vs Inter-Site Replication

Site Links, Cost, and Bridgeheads

A site link is the object that connects two or more sites and carries three settings: a schedule (when replication is allowed), an interval (how often within that schedule), and a cost (a relative preference — lower is better).

Cost is how you describe your WAN to AD. Give the fast MPLS link between head office and the datacentre a cost of 100, and the slow backup VPN a cost of 500, and replication routes over the fast path while it is available. Every new site initially lands on the built-in DEFAULTIPSITELINK; environments with more than two or three sites should replace that with links that reflect the actual network.

Within each site, one DC is selected as the bridgehead server — the single spokesperson that exchanges inter-site replication on behalf of its site, then distributes the changes locally. A component of the KCC called the Inter-Site Topology Generator decides which DC gets the role, and reassigns it automatically if that DC goes down.

What Happens When Replication Breaks

Replication failures are rarely loud. A firewall change, a DNS problem, or a decommissioned DC that never got cleaned up — and one DC quietly stops receiving updates. The directory does not go down. It diverges.

The symptoms show up as user-facing weirdness: a password reset works at head office but the old password still works at the branch. A new starter can log in at one site and does not exist at another. A group membership change grants access to some file servers and not others. Account lockouts behave inconsistently. Every one of these is the same root cause wearing a different costume.

Left unfixed, it gets worse. Deleted objects are kept as tombstones for a limited lifetime — 180 days in forests built on Windows Server 2003 SP1 or later, 60 days in older ones. A DC that fails to replicate for longer than the tombstone lifetime can no longer be trusted: it may hold lingering objects, deleted items it never learned about, which reappear and cause inconsistencies. Windows flags this state with event ID 2042 and blocks replication from that DC.

Scripts / Commands

Use the commands below to check replication health across the forest, inspect a single DC’s partners, force a sync, and review the site topology. All of them are read-only except repadmin /syncall.

# Forest-wide replication health summary - the first command to run
repadmin /replsummary

# Show this DC's replication partners and the last result for each
repadmin /showrepl

# Show replication status for a specific DC
repadmin /showrepl DC2.corp.example.com

# List replication requests still waiting in the queue
repadmin /queue

# Force replication across all partners, all partitions
repadmin /syncall /AdeP

# Run the built-in replication diagnostic test
dcdiag /test:replications

# PowerShell: list every replication failure in the forest
Get-ADReplicationFailure -Scope Forest

# PowerShell: per-partner metadata including last successful sync
Get-ADReplicationPartnerMetadata -Target DC1.corp.example.com

# PowerShell: list sites, site links, and their costs
Get-ADReplicationSite -Filter *
Get-ADReplicationSiteLink -Filter * | Select-Object Name, Cost, ReplicationFrequencyInMinutes

# Check for the too-long-without-replication condition
Get-WinEvent -LogName "Directory Service" -MaxEvents 50 |
    Where-Object { $_.Id -eq 2042 }

Troubleshooting Cheat Sheet

Quick Reference Summary

Final Thoughts

Replication is the reason Active Directory can survive a failed Domain Controller, a severed WAN link, or a whole office losing power — and it is also the layer where neglect accumulates invisibly. A DC can fall weeks behind and nothing turns red until users start reporting problems that look like anything except replication.

The habit that prevents all of it is small: check repadmin /replsummary regularly, keep your sites and subnets honest about what the network actually looks like, and treat any replication failure older than a day as an incident, not a curiosity.