Learn Active Directory - Active Directory Replication

#Introduction

In episode 15 we set who may do what — on files, folders, and AD objects. Now the deeper question: with many Domain Controllers in a domain, how can every DC hold the same information? How can a change you make on the Jakarta DC reach the Surabaya and Makassar DCs? The answer is replication.

From episode 6 you know AD recommends more than one DC for fault tolerance. But that promise only means something if all DCs really hold the same data. Imagine an office with many receptionists each holding an employee directory notebook. If one records a new employee but doesn't sync their notebook with the others, chaos ensues: at desk A the person is "already accepted", at desk B they're "unknown". Replication is the mechanism ensuring all those notebooks stay identical — automatically, continuously, and resilient to failures.

#Multi-Master Replication: No Single King

AD's replication model is called multi-master: every writable DC can accept any change and "broadcast" it to other DCs. There is no single DC that's the one source of truth — unlike the master-slave model in other systems.

The benefit is clear: no single point of failure. Any DC can go offline, and the others keep serving authentication and changes. But this model brings its own challenge: how do you ensure simultaneous changes on two DCs don't overwrite each other? The answer is USNs.

#USN: The Sequence Number of Every Change

The USN (Update Sequence Number) is a monotonically increasing number owned by every DC. Every time an object attribute changes, the DC assigns a new USN higher than the previous ones. With USNs, replication becomes a tidy process:

1. Each DC records "the highest USN I've already received from another DC" (called the high watermark).
2. When replicating, a DC requests "changes with USNs greater than the number I already have".
3. The sending DC provides all those changes, and the receiver updates its watermark.

The analogy is a log book with page numbers: "send me everything I logged after page 42." This is what makes replication incremental — only changes are sent, not the whole database.

AD replication also works per-attribute, not per whole object. If a user only changes their phone number, other DCs only receive that attribute's change — saving bandwidth and time.

repadmin /showobjmeta DC02 "cn=Joko Santoso,ou=Karyawan,dc=corp,dc=local"

#Intra-Site vs Inter-Site Replication

AD distinguishes two replication types based on physical network distance:

#Intra-Site

Within a single site, DCs connect to each other in a ring pattern generated automatically by the KCC (Knowledge Consistency Checker) — AD's "topology architect". When a DC makes a change, it sends a notification to the next DC in the ring, and the change flows quickly. Replication here chases speed, not bandwidth savings.

#Inter-Site

Between sites, AD uses the site links you define in Active Directory Sites and Services — complete with cost, schedule, and replication interval. A low-cost site link means path preference; the schedule determines when replication may run (e.g. only at night for a 2 Mbps link). Instead of all DCs talking to each other, a bridgehead server in each site acts as the representative — one DC exchanging data with the other site.

This is why sites configuration matters so much: if you don't define subnets and sites correctly, branch office clients may "choose" a far DC because they're considered the same site — slow and link-hungry.

#Urgent Replication

Not all changes wait for the schedule. Two change types are considered urgent and immediately replicated across site links:

• Password changes — to prevent a user from using an old password on a DC that hasn't received the update yet.
• Account lockouts — so the lockout policy stays consistent across all DCs.

This matters to understand because it affects user experience: a password reset that "hasn't arrived" often makes users fail to log in — a symptom familiar to helpdesk admins.

#KCC: The Architect That Keeps Paths Connected

The KCC is the engine ensuring every DC always has a replication path to other DCs. It periodically evaluates the topology, creates the needed connection objects, and heals itself if a DC dies or a site link changes. When a DC is promoted, the KCC automatically builds its connections. When another DC dies, the KCC rearranges the ring so replication keeps flowing.

This KCC role is what lets AD "heal itself" for connectivity issues — as long as DNS and the network are healthy.

#RID Pool and Tombstones

Two concepts that often come up alongside replication:

• RID Pool. Every time a DC creates a security object (user, group), it uses a RID (Relative Identifier) to form a unique SID. RIDs are drawn from a pool allocated by the RID Master (one of the FSMO roles, from episode 3). If a DC's pool runs out — e.g. after creating millions of objects — it can't create new objects until the RID Master allocates the next pool. Monitoring the remaining pool prevents a silent "raw material shortage" that blocks user creation.
• Tombstone. Deleted objects in AD don't vanish instantly — they're turned into a tombstone (death marker) that lives for the tombstone lifetime (default 180 days in modern AD). The purpose: replication can spread the deletion to all DCs, and a long-offline DC can "learn" that the object is dead. This is a bridge to the backup and recovery topic in episode 17.

#Monitoring Replication with repadmin

The main replication admin tool is repadmin — e.g. repadmin /replsum for a health summary. Three commands you must master:

repadmin /replsum

repadmin /replsum gives a one-screen summary: per DC, how many failures, how many successes, and what percentage is late. This is the "first dashboard" before diving deeper.

repadmin /showrepl

repadmin /showrepl shows details per destination and source: which connections are healthy, which failed last time, and when. Per-DC:

repadmin /showrepl DC02 -verbose

To force all DCs to sync with all their partners (useful after a fix):

repadmin /syncall -A

#Replication Troubleshooting

When replication fails, the symptoms are distinctive: "old" passwords keep getting rejected on one DC, modified users don't appear on another DC, or GPOs are inconsistent. Some of the most frequent errors:

• Error 1722 (RPC server unavailable) — a DC can't be reached: a firewall is blocking RPC ports (135, 49152-65535), or a service isn't running. Check connectivity and the Kerberos/RPC services.
• Error 8524 (DSA operational failure) — a general outgoing replication failure, often due to security or credential issues between DCs, sometimes USN rollback or DNS issues.
• Error 1256 — the source and destination aren't direct replication partners, or the KCC is still repairing the topology.

The recommended diagnostic sequence:

1. Check DNS first. Replication depends on resolving other DCs' names. If nslookup fails, fix that before blaming replication.
2. Check connectivity. Ensure RPC ports are open between DCs and clocks are synchronized.
3. Read the event log. Directory Service logs (events 1311, 1925, 2042) point straight at the problem.
4. Check with repadmin. repadmin /replsum then repadmin /showrepl narrow down where the failure is.
5. Fix and verify. After the root cause is fixed, force replication with repadmin /syncall -A and confirm failure counters drop.

Two serious conditions to be wary of: USN rollback (a DC restored from an old backup "rewinds" its USNs, triggering event 2042 and potentially corrupting data consistency) and lingering objects (objects already deleted on other DCs but still alive on one DC — residue that's hard to remove). Both need careful intervention, and often the best path is demote, clean up, then promote again.

#Conclusion

In this episode we dissected Active Directory replication: the multi-master model making every DC writable, the USN mechanism as the change sequence number and high watermark for incremental sync, the fast intra-site vs bandwidth-efficient inter-site difference, the role of the KCC and bridgehead servers, the RID pool as SID raw material, tombstones as deletion markers, and monitoring and troubleshooting via repadmin with errors 1722, 8524, and 1256.

The takeaway: replication is a system designed to heal itself — as long as its foundations (DNS, network, time) are healthy. Routine monitoring is what makes many DCs feel like a single directory, not a bunch of unsynced notebooks.

In the next episode 17, we prepare for the worst: Active Directory Backup & Recovery — from system state backup and ntdsutil, authoritative and non-authoritative restore, the Active Directory Recycle Bin, to full forest recovery procedures. Keep the momentum going!