Troubleshoot Active Directory Replication Health

Admin

October 7, 2026

8 min read

Active Directory Domain Services (AD DS) replication distributes directory changes among domain controllers (DCs). A failure can affect logons, policy, DNS records, and applications that query a particular DC. Start by collecting forest-wide status and the failing partner details.

Run these read-only checks from an elevated PowerShell session or command prompt with the Active Directory tools available. Use a privileged account only where access requires it, and protect exported output because it contains internal hostnames and directory topology.

Summarize Replication Failures

Baseline

Run the summary first to see whether failures are isolated to one DC, site, or naming context. Then list replication partners and their last attempt. These commands query status; they do not initiate replication.

repadmin /replsummary
repadmin /showrepl * /csv

Collect DC and Directory Service Diagnostics

Narrow the Scope

Replace the example name with the affected DC. Dcdiag checks several DC functions; the DNS test can help identify locator-record and name-resolution problems. Read the Directory Service log around the first failure time and correlate event details with Repadmin’s failing partner and naming context.

$DomainController = 'DC-BRANCH-01' # Replace with the affected domain controller.
dcdiag "/s:$DomainController" /test:Replications /v
dcdiag "/s:$DomainController" /test:DNS /v
Get-WinEvent -ComputerName $DomainController -LogName 'Directory Service' -MaxEvents 100 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message

❯ Illustrative Output (Results Vary)

Starting test: Replications
         [Replications Check,DC-BRANCH-01] A recent replication attempt failed:
            From DC-HUB-01 to DC-BRANCH-01
            Naming Context: DC=corp,DC=example,DC=com
            The RPC server is unavailable.

Verify the Partner Can Be Located and Reached

Dependencies

Replication depends on DNS, network connectivity, authentication, time, and the directory database. Check the failing partner’s host and domain-controller locator records, then confirm that approved firewall paths and time synchronization are healthy. A successful ping alone does not verify RPC or AD replication.

Resolve-DnsName DC-HUB-01.corp.example.com
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example.com
nltest /dsgetdc:corp.example.com /force
w32tm /monitor

Match the Error to Its Likely Dependency

Classify

Use the first failing event and error code to choose the next check. Record the source and destination DC, naming context, first failure time, last successful replication, event IDs, and recent changes. If several DCs or naming contexts fail together, treat it as a broader incident.

1722 RPC unavailable       -> partner connectivity, DNS, approved RPC/AD ports
5 Access denied            -> DC secure channel, Kerberos, restore/clone history
2087/2088 name resolution  -> AD DNS zones, locator records, DC DNS settings
Tombstone lifetime warning -> stop; follow supported stale-DC recovery guidance
Single naming context      -> confirm the partition is expected on both DCs

❯ Illustrative Output (Results Vary)

Finding: 1722 from DC-HUB-01 to DC-BRANCH-01
Next checks: confirm partner DNS answer and approved RPC path
Change made: none until the failing dependency is verified

Confirm Replication Has Recovered

Verify

After the underlying issue is corrected through change control, rerun the summary and targeted checks. Confirm each affected naming context reports a recent successful attempt, then review new Directory Service events. Use repadmin /syncall only when an approved procedure calls for it and you understand its scope; it can propagate changes broadly.

repadmin /replsummary
repadmin /showrepl DC-BRANCH-01
dcdiag /s:DC-BRANCH-01 /test:Replications