Replication health

Start with the destination

AD replication pulls changes. Even an operation described as a push asks another DC to pull. Start with the DC that isn’t receiving updates, then find the source and naming context involved.

Run these from an administrative workstation or DC with the AD DS management tools and permission to query the target DCs. Forest-wide queries need connectivity to every target and can take time.

repadmin /replsummary
repadmin /showrepl * /csv > replication-status.csv
repadmin /viewlist *

Check destination failures and largest delta in the summary. The totals count replication relationships for naming contexts, rather than partner machines. Also check which DCs made it into the report: a DC with no inbound neighbors may be missing from the destination list. Use the detailed report to find each source, partition, last attempt, last success, and error. See the Repadmin reference.

Get objects you can filter

With the ActiveDirectory PowerShell module:

Get-ADReplicationPartnerMetadata -Target 'contoso.com' -Scope Domain `
    -Partition '*' -PartnerType Inbound |
    Select-Object Server, Partner, Partition,
        LastReplicationSuccess, LastReplicationAttempt, LastReplicationResult

Get-ADReplicationFailure -Target 'contoso.com' -Scope Forest |
    Select-Object Server, Partner, FirstFailureTime, FailureCount, LastError

Get-ADReplicationFailure -Target 'Australia-East' -Scope Site

Keep failed queries in the report too. No rows from an unreachable DC doesn’t mean it passed. Export the objects before using Format-Table if you’ll process the report later. Microsoft’s PowerShell topology guide has more examples.

Check the dependencies

From the affected destination, investigate DNS, RPC, and authentication to its source. DNS must resolve the source DC’s host name and its DSA GUID CNAME under the forest’s _msdcs zone. RPC needs the endpoint mapper and the endpoint it returns; a successful TCP 135 check alone does not prove replication connectivity.

repadmin /showrepl DC1 /verbose
dcdiag /s:DC1 /test:CheckSecurityError /v
dcdiag /s:DC1 /test:DNS /DnsBasic /v
w32tm /monitor

Test-NetConnection -ComputerName 'DC2.contoso.com' -Port 135

Read the exact error before choosing the next test. An RPC error, target principal error, access denial, and quarantined replica need different investigations. Microsoft’s replication troubleshooting guidance and service port requirements cover those dependencies.

Observe before forcing a cycle

repadmin /queue DC1
repadmin /showoutcalls DC1
repadmin /failcache DC1

Changes replication activity: after fixing a known dependency, this requests one partition from one source:

repadmin /replicate DC1 DC2 "DC=contoso,DC=com"

The destination is first. A successful retry tells you about that request; you’ll still need to check the rest of the forest. Collect the detailed status again and compare both directions where appropriate.

Health and convergence answer different questions

Successful attempts don’t tell you how long a new change takes to reach every required replica. Measure convergence separately with an approved dedicated test object. Record the originating DC, naming context, expected replicas, and elapsed time, allowing for schedules and RODCs. Keep the original probe value, restore it afterwards, and check that cleanup reaches the other replicas too.

Account for every expected replica

Keep an inventory from each forest domain beside the summary. Then ask each relevant DC which naming contexts it actually hosts:

Get-ADRootDSE -Server 'DC1.contoso.com' |
    Select-Object -ExpandProperty namingContexts

The domain NC, schema, configuration, DNS application partitions, and GC partial replicas have different replica sets. Don’t expect ForestDnsZones on a DC that isn’t enlisted for it. A healthy domain-NC relationship also tells you nothing about a failed DNS application-NC relationship. The Get-ADReplicationPartnerMetadata reference covers partition and partner-type selection.

For collection scripts, preserve query failure separately from a successful result containing zero rows. Use -ErrorAction Stop and record the target and exception in catch; otherwise a permissions, ADWS, or RPC failure can quietly reduce the apparent inventory.

Read the summary as an aggregate

repadmin /replsummary * /bysrc /bydest /sort:delta

The source view shows which sources have relationships reported as failing; the destination view helps find the DC that can’t pull. Both describe the same problem, rather than separately testing pushes and pulls. When largest delta is high, check the relationship’s last success against its intended schedule. “No errors” with an old success can still mean changes are arriving too slowly. The summary command reference describes the sort and view switches.

Distinguish current activity from stored status

/queue shows inbound replication work at that moment. An empty queue may just mean nothing is scheduled. /showrepl reports relationship status rather than comparing every object’s values. /showoutcalls shows calls currently in progress, so it’s often empty between operations.

For one disputed change, query the same object GUID and attribute against explicit DCs, then compare attribute metadata. Confirm that the attribute is supposed to exist on the destination, especially for a GC partial replica or RODC. If values diverge while status looks healthy, include restore history and USN rollback in the investigation; replication success alone cannot exclude that class of failure.

Turn an error into the next test

Use the error-by-stage guide to avoid repeated broad synchronization attempts. Error 1256 may follow an earlier transport failure; 8453 may belong to the interactive caller; a GUID CNAME lookup can fail while fallback still permits replication. Keep timestamps and relationship direction with the error so the next test answers the failing operation’s actual question.

Distinguish a busy queue from a stalled queue

Collect /queue and /showrepl DC1 /verbose more than once, with timestamps. Are the current task, oldest queued task, source, NC, and progress changing? A busy queue that keeps completing tasks is different from one stuck on the same task. Repeated broad manual synchronization can add higher-priority work and keep preempting ordinary work.

Status 8461 means preemption; it does not inherently mean a broken network. Event 1839 gives the oldest waiting operation and queue size; 2094 identifies delayed application of a particular object. 1580 records a long-running task’s completion when the appropriate replication diagnostic logging is enabled. These distinguish waiting from expensive processing. Correlate CPU, storage latency, database pressure, source workload and transport evidence before changing concurrency. Microsoft’s 8461 investigation explains priorities and queue trends.

In verbose relationship output, OU and PU are source-relative object/property progress markers, not organizational units and not two forest-wide counters. Movement can show that a long cycle is still making progress. Compare the same source incarnation and NC over time; do not compare their magnitudes across different DCs or subtract them as a reliable pending-object count.

Status 8477 can accompany queued/preempted work or an initial synchronization still running. Schema differences can prevent another partition’s updates from being interpreted until the required schema has arrived. Large legacy, non-LVR membership updates can also consume disproportionate work; inspect the named object, event details and metadata rather than treating the entire backlog as equal-sized objects. The 8477 investigation covers these branches. A marker arriving partway through a cycle does not certify that the cycle and its full knowledge vector have completed.