Active Directory replication has two directions in every report: a destination DC receives a naming context from a source partner. If those three facts are missing, “replication is broken” is not yet a diagnosis.

Read the forest-wide summary first

Capture:

repadmin /replsummary
repadmin /showrepl * /csv
dcdiag /e /test:Replications /v

The summary shows breadth and age. The detailed report shows the inbound partner, partition, last attempt, last success and status code. Preserve both with timestamps.

Check every replicated naming context: domain, Configuration, Schema and DNS application partitions. A healthy domain partition beside a stale Configuration partition can still break topology or service discovery.

Build one precise failure statement

Example:

Destination <DC-B> has not received <naming-context> from source <DC-A> since <time>; attempts fail with <code>.

Now determine whether the connection is expected by site/link topology. Replication from a DC that is not a valid source for that partition can fail even though both machines are healthy.

Diagnose dependencies before forcing sync

Microsoft groups common root causes into network, DNS, authentication/authorisation, directory store, replication engine/scheduling and topology.

Check in that order:

  1. Network/RPC: both directions, required ports, firewalls, VPN/WAN and endpoint availability.
  2. DNS: source GUID/host records, locator records, authoritative answers and DC DNS-client settings.
  3. Time/Kerberos: source, offset, tickets and machine-account/secure-channel state.
  4. Directory/store: disk, database/log, resource pressure and service events.
  5. Topology: sites/subnets, site links, schedules, connection objects and KCC events.
  6. Age/safety: last success, tombstone lifetime, lingering-object and rollback evidence.

Resolve the first proven cause. Do not delete topology objects or reset channels merely because an error family mentions them.

Use error codes as routing evidence

An error code narrows the branch; it does not supply a universal fix.

  • Name-resolution errors require checking the exact source record and DNS server used by the destination.
  • RPC unavailable requires separating name resolution, routing/firewall and service endpoint state.
  • Access denied requires time, Kerberos, secure channel, account/permission and duplicate-SPN evidence.
  • Naming-context errors require checking partition presence and topology, not repeated sync attempts.
  • Long divergence requires tombstone/lingering-object assessment before reconnection.

Use the matching current Microsoft troubleshooting article for the exact code and retain its prerequisites and stop conditions.

Make a controlled repair

State the hypothesis, target and expected observable change. Examples include correcting a DC’s DNS client, repairing one blocked network path, restoring time hierarchy or fixing an invalid site/subnet mapping.

Avoid repadmin /syncall as a reflex. It can spread an unwanted change or flood an unhealthy topology. First prove the source is good and the destination/partition relationship is intended. Then trigger only the necessary replication if natural scheduling is too slow for the maintenance window.

Prove convergence, not command success

After repair:

  1. repeat showrepl and confirm a new successful inbound attempt for the exact pair and partition;
  2. confirm error age/count is falling across the whole summary;
  3. create or modify an approved synthetic test object on its normal originating DC;
  4. read that object’s same attribute/version from every intended DC after the expected site schedule;
  5. verify Configuration/Schema/DNS partitions where the incident affected them;
  6. confirm DC Locator, authentication and Group Policy from an affected site; and
  7. check that no new KCC, NTDS, DNS or storage failures appeared.

repadmin returning zero for one forced call proves only that call. Convergence means the intended topology carries normal changes to every required replica and client services use the result.

Close with cause and recurrence controls

Record the failed dependency, why it failed, maximum divergence, objects/partitions at risk, repair, convergence evidence and monitoring change. Add alerts for replication last-success age, DNS/DC availability, time and storage.

If the failed DC is unsafe to reintroduce, stop repairing it in place. Rebuild or remove it through the supported demotion/metadata-cleanup path after roles and dependencies are reconciled.