How to Set Up AD Replication Between Domain Controllers on Windows Server 2025

How to Set Up AD Replication Between Domain Controllers on Windows Server 2025

Active Directory replication is the process by which changes made on one domain controller — whether a new user account, a password reset, or a Group Policy update — are propagated to every other domain controller in the domain. Without healthy replication, domain controllers diverge: users may be unable to authenticate, Group Policy may not apply consistently, and DNS records may become stale. Windows Server 2025 inherits the same Knowledge Consistency Checker (KCC) and replication engine as previous versions but adds improved diagnostics and health reporting. This tutorial covers the replication architecture, monitoring tools, common failure scenarios, and remediation steps that every AD administrator should master.

Prerequisites

• At least two Windows Server 2025 domain controllers deployed in the same domain.
• Active Directory PowerShell module and AD DS Role Tools installed (Add-WindowsFeature RSAT-ADDS-Tools).
• Administrative credentials with Domain Admins or equivalent rights.
• Network connectivity between DCs on TCP/UDP 389, 636, 3268, 49152–65535 (RPC dynamic).

Step 1: Understand the Replication Architecture

Active Directory uses a multi-master replication model: every domain controller can accept writes (except for FSMO role-specific operations) and replication moves those changes outward to peers. Two key concepts govern how the replication topology is built:

• Knowledge Consistency Checker (KCC): A built-in service on every DC that automatically calculates and maintains the replication topology. The KCC creates connection objects that define which DCs replicate directly with each other. It recalculates the topology every 15 minutes.
• Intrasite vs. Intersite Replication: DCs within the same AD site replicate via intrasite replication — triggered immediately on change and using an uncompressed RPC channel. DCs in different sites replicate via intersite replication, which is scheduled (default: every 180 minutes) and uses compressed data to reduce WAN utilisation.

The replication unit is the Update Sequence Number (USN). Each DC maintains its own USN counter; when an object changes, the DC stamps the change with the next USN. Replication partners track the highest USN they have received from each source DC, requesting only changes they have not yet seen.

Step 2: View the Current Replication Topology

Use repadmin, the primary command-line tool for AD replication diagnostics:

# Show all replication partners and connection objects for the local DC
repadmin /showrepl

# Show replication partners for a specific DC
repadmin /showrepl DC02.corp.local

# Show a compact summary of inbound replication for all DCs in the domain
repadmin /replsummary

# Show the replication queue (pending inbound changes)
repadmin /queue

# Show the replication queue for a specific DC
repadmin /queue DC03.corp.local

The output of repadmin /replsummary is the fastest way to spot replication lag — any DC showing a large number of failures or a “largest delta” value in hours warrants immediate investigation.

Step 3: Force Immediate Replication

During initial DC promotion or after making urgent changes (new GPO, critical user account change), you can force replication rather than waiting for the scheduled interval:

# Synchronise a specific naming context from a specific source DC
repadmin /sync DC=corp,DC=local DC01 {DC02-ObjectGUID}

# Force full synchronisation of all naming contexts from all partners
repadmin /syncall /AdeP

# Parameters explained:
# /A  - synchronise all naming contexts
# /d  - identify servers by Distinguished Name
# /e  - enterprise-wide (cross-site)
# /P  - push: initiate outbound replication

# Alternatively, via PowerShell:
Sync-ADObject -Object "DC=corp,DC=local" -Source DC01 -Destination DC02

In the Active Directory Sites and Services MMC, you can right-click any connection object under NTDS Settings and select Replicate Now for a GUI-driven forced sync.

Step 4: Diagnose Replication Failures with dcdiag

dcdiag runs a comprehensive set of tests against domain controllers, including dedicated replication tests:

# Run only the replication test against all DCs
dcdiag /test:replications

# Run replication test against a specific DC
dcdiag /test:replications /s:DC02

# Run all tests with verbose output and save to a file
dcdiag /test:replications /v /f:C:Logsdcdiag-repl.txt

# Comprehensive health check including connectivity, DNS, and replication
dcdiag /test:replications /test:connectivity /test:dns /v

Focus on lines containing FAILED or WARNING. Each failure includes an error code that maps to a specific replication issue.

Step 5: Identify Common Replication Errors

The Windows Event Log (under Directory Service in Event Viewer) records replication events. Key Event IDs to monitor:

• Event ID 1311: The KCC could not build a spanning tree replication topology. Usually indicates network connectivity issues between sites or missing site link bridges.
• Event ID 1308: The Knowledge Consistency Checker (KCC) has detected that successive attempts to replicate with a DC have consistently failed. The source DC may be offline or unreachable.
• Event ID 1388: Another DC has asked for a lingering object — an object that was deleted on this DC during tombstone lifetime but still exists on the source DC. Requires manual cleanup.
• Event ID 2042: Replication has not occurred for longer than the tombstone lifetime. The DC is in a “tombstone expired” state and may need to be demoted and re-promoted.

# Query Directory Service event log for replication errors
Get-WinEvent -LogName "Directory Service" -MaxEvents 100 |
    Where-Object { $_.LevelDisplayName -in @("Error","Warning") } |
    Select-Object TimeCreated, Id, Message |
    Format-Table -AutoSize -Wrap

# Filter for specific replication Event IDs
Get-WinEvent -LogName "Directory Service" |
    Where-Object { $_.Id -in @(1311, 1308, 1388, 2042) } |
    Select-Object TimeCreated, Id, Message

Step 6: Temporarily Disable Outbound Replication for Troubleshooting

When a DC is misbehaving and pushing corrupt or unwanted changes, disable its outbound replication while you investigate:

# Disable outbound replication on the local DC (stops it from sending changes)
repadmin /options DC01 +DISABLE_OUTBOUND_REPL

# Verify the option is set
repadmin /showattr DC01 "CN=NTDS Settings,CN=DC01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=corp,DC=local" /atts:options

# Re-enable outbound replication after investigation
repadmin /options DC01 -DISABLE_OUTBOUND_REPL

# Similarly, disable inbound replication
repadmin /options DC01 +DISABLE_INBOUND_REPL

# Re-enable inbound replication
repadmin /options DC01 -DISABLE_INBOUND_REPL

Step 7: Prevent and Recover from USN Rollback

A USN rollback occurs when a domain controller’s USN counter is artificially rolled back — typically because a VM snapshot was incorrectly restored without using VM-Generation ID protection. Replication partners believe they have already received changes up to the snapshotted USN, so they stop requesting updates, causing silent divergence.

# Check whether USN rollback protection is active (VM-GenerationID)
# On a Hyper-V guest, this is automatic on Windows Server 2012+

# Detect a potential rollback victim by comparing USNs
repadmin /showutdvec DC01

# If a rollback is suspected, check replication metadata for inconsistencies
repadmin /showmeta "CN=krbtgt,CN=Users,DC=corp,DC=local"

# The safest recovery is to demote and re-promote the affected DC:
# 1. Seize or transfer any FSMO roles away
# 2. Demote: Uninstall-WindowsFeature AD-Domain-Services
# 3. Promote fresh: Install-ADDSDomainController

Prevention: Always use the Hyper-V checkpoint (not snapshots) for AD-integrated VMs, or use a dedicated DC backup solution like Windows Server Backup with System State. Never restore a DC from a snapshot older than the tombstone lifetime (default 180 days).

Step 8: Monitor Replication Health Continuously

# Create a scheduled replication health report
$report = repadmin /replsummary 2>&1
$timestamp = Get-Date -Format "yyyy-MM-dd_HH-mm"
$report | Out-File "C:Logsrepl-health-$timestamp.txt"

# Use Get-ADReplicationFailure for PowerShell-native monitoring
Get-ADReplicationFailure -Scope Domain -Target "corp.local" |
    Select-Object Server, FirstFailureTime, FailureCount, LastError |
    Sort-Object FailureCount -Descending |
    Format-Table -AutoSize

# Check replication partner metadata
Get-ADReplicationPartnerMetadata -Target "DC01.corp.local" |
    Select-Object Partner, LastReplicationSuccess, LastReplicationAttempt, LastReplicationResult |
    Format-Table -AutoSize

Conclusion

Active Directory replication is the circulatory system of your domain — when it stops working, every AD-dependent service degrades. On Windows Server 2025, the combination of repadmin, dcdiag, and the ActiveDirectory PowerShell module provides a complete toolkit for monitoring topology health, diagnosing failures, and performing targeted remediation. Building replication health checks into a scheduled monitoring task and alerting on Event IDs 1311, 1308, and 1388 ensures failures are caught early, before they escalate into widespread authentication or Group Policy failures. Consistent site link configuration, proper network connectivity, and snapshot hygiene on virtualised DCs are the foundations of a resilient replication environment.