🧠 1. Domain Controllers (DCs)
Think of each Domain Controller as a librarian in a giant library chain. Every DC stores a copy of the same book (the Active Directory database). When one librarian updates a book, the others must update their copies. That's replication.
Source DC
A DC that sends changes to its replication partners. It's the source of the new information.
Destination DC
A DC that receives changes from a replication partner. It's updating its copy of the database.
🔁 Replication happens between DCs through replication partners, like a controlled telephone tree where updates are passed along to ensure consistency across the entire domain.
📘 2. NTDS.DIT (Active Directory Database)
Think of NTDS.DIT as the master book each librarian (Domain Controller) maintains. It is the physical database file for Active Directory.
What's Inside?
- 🧑 All user, group, and computer accounts
- 📁 OUs, GPO links, and schema objects
- 📈 Metadata like
whenCreated,whenChanged, and version numbers
🧩 Important: Changes are not replicated as entire records. Only the specific changed attributes are replicated, which is highly efficient. The physical file is located at %SystemRoot%\NTDS\ntds.dit.
🔢 3. USN (Update Sequence Number)
Think of the USN as a serial number that only goes up. Every DC maintains its own USN counter. Every time an object is created, modified, or deleted on a DC, its local USN counter increases by 1.
Interactive Demo: How USN Works
DC1
Originates changes
1000
DC2
Asks for changes after...
950
During replication, DC2 asks DC1:
"Give me everything after USN 950."
This is delta replication — only what has changed since the last sync is sent.
🏷️ 4. Replication Metadata & Attribute Versioning
Every single attribute in Active Directory has a hidden "change log tag" attached to it. This metadata is crucial for resolving conflicts in a multi-master environment.
Key Metadata Fields
| Metadata Field | Description |
|---|---|
| Version Number | Increases every time the attribute is modified. |
| Originating USN | The USN on the DC where the change was first made. |
| Originating DC GUID | Uniquely identifies which DC made the change. |
| Timestamp | When the change occurred. |
📦 Why is this important? If two people update the same user on different DCs at the same time, AD uses this metadata to resolve the conflict intelligently (usually "last-writer-wins").
📊 5. High-Watermark Vector Table
This is a table kept by a destination DC for each of its replication partners. It's like a bookmark, telling the DC: "For this specific partner, I've already received all changes up to USN X."
Replication Example
- DC1 makes 10 changes. Its USN goes from 100 to 110.
- DC2's High-Watermark for DC1 is currently 100.
- During the next replication, DC2 asks DC1: "Give me changes since USN 100."
- DC1 sends the changes associated with USNs 101 through 110.
- After successfully applying the changes, DC2 updates its High-Watermark for DC1 to 110.
🛡️ This ensures replication is efficient and avoids sending the entire database. If a DC misses a replication cycle, the High-Watermark tells it exactly where to resume.
🕒 6. Up-To-Dateness Vector Table (UTD Vector)
Where the High-Watermark is per-partner, the UTD Vector is global. It tracks the highest originating USN a DC has seen from every other DC in the forest, regardless of which partner sent the change.
Preventing Duplicate Changes
Imagine this scenario:
- DC1 makes a change (originating USN 101).
- DC3 replicates this change from DC1.
- DC2 then replicates from DC3 and receives the change (originating from DC1, USN 101). DC2 updates its UTD vector to note it has seen USN 101 from DC1.
- Later, DC2 replicates directly with DC1. Without the UTD Vector, DC1 would try to send USN 101 again.
- DC2 checks its UTD Vector, sees it already has this change, and tells DC1 not to send it.
✅ The UTD Vector prevents redundant replication traffic and ensures changes are only applied once, making replication efficient in complex topologies.
🔗 7. Connection Objects
A Connection Object is a one-way "link" in Active Directory that tells a Destination DC to pull replication changes from a specific Source DC. They are the building blocks of the replication topology.
One-Way Street
A connection from DC1 to DC2 allows DC2 to pull from DC1. For two-way sync, a second connection object (DC2 to DC1) is required.
Who Creates Them?
These are almost always created automatically by the KCC (Knowledge Consistency Checker). Admins can create them manually, but it's rarely needed.
👁️ You can view these objects in the Active Directory Sites and Services tool, under each server's NTDS Settings object.
🧠 8. KCC (Knowledge Consistency Checker)
The KCC is a built-in process that runs on every DC. Think of it as the network planner or air traffic controller for replication. Its primary job is to automatically create and maintain the replication topology by creating Connection Objects.
What does the KCC do?
- Scans the site topology (site links, costs, schedules).
- Creates a resilient and efficient replication path (often a ring).
- Ensures that if a DC goes down, it can create new paths to work around it.
- Runs every 15 minutes by default to adapt to changes.
💡 Think of the KCC like Google Maps for AD data: it figures out the best route for changes to flow between DCs and automatically reroutes if there's a problem.
🌐 9. Replication Topology: Intra-site vs. Inter-site
The rules for replication change depending on whether DCs are in the same physical location (site) or different ones. This is designed to be efficient over both fast LANs and slower WANs.
🏠 Intra-site Replication
(Inside the same site)
- Trigger: Change notification (near real-time).
- Frequency: ~15 seconds.
- Compression: ❌ No (fast LAN assumed).
- Protocol: RPC over TCP.
🌍 Inter-site Replication
(Between different sites)
- Trigger: Runs on a schedule.
- Frequency: Default is 180 minutes (3 hours).
- Compression: ✅ Yes (to save WAN bandwidth).
- Protocol: RPC over TCP or SMTP.
📥 10. Replication Queues
When a change occurs, it doesn't get sent immediately. It's first placed in an outbound queue for each replication partner. This ensures reliability even if a partner is temporarily offline.
How it works
- DC1 makes 20 updates.
- DC2 is offline for maintenance.
- The 20 updates for DC2 are stored in DC1's outbound replication queue for DC2.
- When DC2 comes back online and replication begins, DC1 sends all 20 changes from its queue.
🛠️ A long queue can indicate a replication problem, like a network issue or an offline DC. Admins can use repadmin /queue to check for backlogs.
⏱️ 11. Replication Triggers
Replication doesn't run constantly. It's triggered by specific events and rules.
Change Notification (Intra-site)
When a change is made, the DC waits about 15 seconds and then notifies its partners within the same site to come and get the update. This is why intra-site replication is so fast.
Scheduled Replication (Inter-site)
DCs in different sites don't use notifications. They replicate based on a schedule defined on the site link (e.g., every 3 hours). This conserves WAN bandwidth.
Manual & Other Triggers
Replication can also be manually forced by an admin (e.g., via AD Sites and Services or `repadmin`), or triggered by events like a DC reboot or a KCC topology update.
🛠️ 12. Monitoring Replication: Tools
Several powerful command-line and GUI tools are available to check, test, and troubleshoot Active Directory replication health.
repadmin
The most powerful and versatile tool for managing AD replication. Here are some key commands:
repadmin /replsummary
# Show detailed replication status for a DC
repadmin /showrepl DC01
# Check the replication queue
repadmin /queue
# Force sync to a DC from all its partners
repadmin /syncall DC01 /AdeP
dcdiag
A comprehensive diagnostic tool that runs dozens of tests, including replication checks.
dcdiag /s:DC01
# Run only the replication tests
dcdiag /test:replications
Other Tools
- Active Directory Sites and Services: GUI to view topology and force replication.
- Event Viewer: Check the "Directory Service" log for replication errors.
- PowerShell: Use `Get-ADReplication*` cmdlets.