When replication between Domain Controllers breaks, changes to users, groups, passwords and configuration may not reach every DC in time. The first step is not to force replication, but to find out which DC and which naming context are failing, and with which error.
Symptoms
- AD changes do not show up on another DC.
repadminreports errors.- Replication events appear in the Directory Service log.
- User or group information is inconsistent between DCs.
1. Get a replication summary
repadmin /replsummaryThis output is my starting point for quickly seeing which DCs have errors.
2. Look at the detailed replication status
repadmin /showreplFor a forest-wide report (create the C:\Temp folder first):
repadmin /showrepl * /csv > C:\Temp\showrepl.csvReview the source and destination DC, the naming context, the last successful replication and the error code together.
3. Check Domain Controller health with DCDiag
dcdiag /test:replications
dcdiag /test:dns4. Check DNS
AD replication depends on DNS resolution. Confirm that the DCs can resolve each other’s FQDNs and that the AD DNS records are healthy.
nslookup dc02.contoso.com
ipconfig /alldc02.contoso.com is only an example; use the name of your own replication partner.
5. RPC, network and firewall
For errors such as 1722 - The RPC server is unavailable, do not focus on repadmin alone. Check network access between the DCs, RPC, DNS and the firewall rules.
6. Time and Kerberos
Large time differences between DCs can affect Kerberos authentication and often come together with replication problems. Verify the PDC Emulator and the domain time hierarchy.
7. The Directory Service event log
In Event Viewer, open the Directory Service log and review the NTDS Replication and KCC events that match the time of the error in the repadmin output. Treat the error code as part of the diagnostic chain, not as the root cause.
8. Before you force replication
Running repadmin /syncall over and over while a DNS, RPC or authentication problem is still there does not fix the root cause. Classify the error with /replsummary and /showrepl first.
My troubleshooting flow
repadmin /replsummaryrepadmin /showrepl- Identify the failing source and destination DC and the naming context.
- Verify DNS resolution.
- Check RPC and network access.
- Check time and Kerberos.
- Compare with the Directory Service events.
- After fixing the root cause, verify the replication status again.
Validate after the fix
After the root cause is fixed, run repadmin /replsummary and repadmin /showrepl again. Check the last successful replication time and the error count, and confirm that the change now appears on the other DC.
Conclusion
AD replication troubleshooting should verify the dependencies in order instead of applying random fixes for an error code. Used together, repadmin, DCDiag, DNS and the Directory Service events separate the failing replication partner and the root cause much faster.