Skip to content
WindowsDeep Dive Published Updated 8 min readViews unavailable

Active Directory Replication Diagnostics: Read Repadmin Before Forcing Sync

Troubleshoot Windows AD replication by mapping naming contexts, reading Repadmin evidence, and tracing DNS, RPC, authentication, topology, and database dependencies.

Active Directory Domain Services (AD DS) replication distributes directory changes among domain controllers according to naming context, site topology, and connection schedules. When an object appears on one domain controller but not another, repeated manual synchronization is not a diagnosis. The discrepancy can be caused by DNS, RPC connectivity, authentication, time, topology, a disabled connection, a lingering partition issue, or a directory database constraint. Forcing replication before identifying the failing dependency can obscure the timeline and create additional load without correcting the cause.

Start by defining exactly which object, attribute, source domain controller, destination domain controller, naming context, and time interval are involved. Record whether the symptom is a missing change, a stale value, a failed password operation, a Group Policy inconsistency, or a DNS record difference. Identify whether the affected DCs are in the same site, across a site link, or in different domains. AD replication is not one global “sync” operation: each naming context can have a different set of partners and health state.

Build a replication evidence snapshot

Collect current status from an administrative system with the Remote Server Administration Tools (RSAT) for AD DS. Use repadmin to capture both a forest-wide summary and the per-partner view. Preserve raw output with UTC timestamps before making changes:

$utcStamp = [DateTime]::UtcNow.ToString('yyyyMMdd-HHmmssZ')
$capture = Join-Path $PWD ('ad-repl-' + $utcStamp)
New-Item -ItemType Directory -Path $capture -ErrorAction Stop | Out-Null

repadmin.exe /replsummary |
    Out-File (Join-Path $capture 'replsummary.txt') -Encoding utf8

repadmin.exe /showrepl * /csv |
    Out-File (Join-Path $capture 'showrepl.csv') -Encoding utf8

repadmin.exe /queue |
    Out-File (Join-Path $capture 'queue.txt') -Encoding utf8

These commands query and save status; they do not initiate replication. The output format and available columns vary by Windows Server and RSAT version. replsummary helps identify DCs with failures and largest deltas. showrepl exposes inbound partner results for naming contexts. A queue may be transiently nonempty during normal activity; interpret it with the number of DCs, replication schedule, change volume, and recent successes. Do not treat a zero queue as proof that every required partner is healthy.

For a focused pair, run repadmin /showrepl <DestinationDC> and inspect the exact naming context and source partner. Note last successful attempt, last failure, error status, transport, site, and whether the partner is expected by topology. A failure on one partition can coexist with success on others. Compare the same naming context on both ends. Use repadmin /showobjmeta only for a specific object and attribute when metadata comparison is needed; it is not a substitute for a broad replication health report.

Trace the dependency chain

Microsoft identifies network connectivity, DNS, authentication and authorization, time accuracy, the directory database, replication topology, and the replication engine as dependencies. Check them in an order that preserves cause-and-effect evidence:

  1. Verify that the source and destination DCs are online and that their host names resolve to the expected addresses from both sides.
  2. Confirm that domain controller locator records, site/subnet mapping, and SRV records point clients and DCs to intended partners.
  3. Check the route, firewall and RPC dynamic-port path between the DCs using the organization’s approved network diagnostics.
  4. Verify time synchronization and Kerberos health, then secure channel and machine-account state.
  5. Inspect Directory Service, DNS Server, System, and security logs on both partners for the same time window.
  6. Check site links, schedules, bridgehead availability, connection objects, and whether the KCC generated the expected topology.
  7. Review disk health, database/log volumes, free space, and NTDS/ESENT events on the destination.

dcdiag /test:dns /v can help assess DC DNS registration and resolution, but read the failing test and the host on which it ran. A DNS test from an administrator’s workstation is not equivalent to a DC’s own resolver path. Use nltest /dsgetdc:<domain> from relevant systems to see DC locator results, and query authoritative DNS servers when records differ. Do not change DNS client settings to point a DC at a public resolver; domain controllers need the intended internal DNS architecture to locate AD services.

Use targeted network evidence rather than opening broad firewall ranges or disabling the host firewall. RPC endpoint mapping and dynamic RPC ports are part of the AD DS communication path; the exact policy must match the organization’s Windows Server versions and network segmentation. A successful ping or TCP test to one known port does not prove that the full replication protocol path works. Collect connection logs or a scoped packet capture when the status code indicates a transport or RPC problem.

Interpret failures and topology carefully

Replication status codes are clues, not root causes by themselves. DNS name resolution errors point toward records, client resolver paths, or stale registration. Access denied or Kerberos errors require examination of secure channels, time, SPNs, trust, and authentication context. RPC unavailable can indicate route, firewall, endpoint mapper, service state, or DNS resolving to the wrong address. A disk or database error can indicate local storage and should not be treated as a network outage. Read Microsoft’s current error guidance for the exact numeric status and capture the full message.

Confirm the naming context being replicated. Domain, configuration, schema, application directory partitions, and DNS application partitions can have different replication scope. For an AD-integrated DNS zone, an answer discrepancy may result from replication of its application partition, not a standard DNS zone transfer. A conventional secondary zone uses DNS transfers and serial numbers instead. Determine the zone type before running directory diagnostics or changing zone transfer settings.

Review Active Directory Sites and Services for the correct subnet-to-site mapping, site links, costs, schedules, and connection objects. The Knowledge Consistency Checker (KCC) builds topology based on these objects and connectivity assumptions. A manually created or disabled connection can affect expected behavior. Do not delete connection objects just because they appear unfamiliar; verify the topology design, owner, and replication route first. If a site link schedule delays replication, the delay may be expected and not a failure.

A rising largest delta deserves investigation but must be interpreted against configured schedules and legitimate isolated sites. Compare last success to the expected interval. Long disconnections can exceed the forest’s tombstone lifetime and become a risk for lingering objects. Do not reintroduce a stale DC into replication as if it were an ordinary transient outage. Follow Microsoft’s guidance for the exact status and consult the directory service owner before metadata cleanup or forced demotion.

Avoid destructive or misleading shortcuts

repadmin /syncall triggers synchronization and can create a broad wave of replication traffic. It does not repair incorrect DNS, authentication, topology, or storage. Do not use it as the first diagnostic command or repeat it until the observed issue disappears. If a targeted synchronization is justified after the cause is understood, scope it to the intended DC and naming context, capture before-and-after evidence, and make the action part of an approved change.

Do not edit ntds.dit, remove database log files, delete connection objects, change invocation IDs, or clean metadata based on a generic “replication failed” dashboard. A forced demotion or metadata cleanup changes directory state and can affect replication partners, DNS, sites, and object ownership. Use the current Microsoft procedure for supported recovery, take an appropriate system-state backup, and involve the AD DS owner. For a domain controller with a database or storage failure, preserve logs and backup state before any repair.

Avoid using a single admin workstation’s cached credentials or resolver results as the only test. Logon and object reads can be served by different DCs. Record the DC selected by the client, query each partner directly with tools appropriate to the object type, and compare the actual attribute metadata. If authentication succeeds, that only proves the selected path; it does not show that every replica has converged.

Remediation and validation loop

After identifying the failed dependency, make the narrowest repair and preserve a before snapshot. For a DNS record issue, correct the authoritative record or DC registration and verify SRV and host lookups from both partners. For a network path issue, implement only the required scoped firewall or routing change. For time or trust, follow the supported recovery path and verify Kerberos. For topology, correct the site/subnet or link configuration under change control and allow the KCC to recompute as designed. For database or disk health, resolve the underlying storage issue before reattempting replication.

Re-run repadmin /showrepl and /replsummary after a change and compare last-success timestamps and per-partition status. Confirm the affected object or attribute on the destination DC and a second relevant replica. For DNS partitions, query the authoritative servers directly. Review the same event logs for new failures and check that the replication queue drains as expected. Keep the initial and final reports with the ticket, including the DC that witnessed each test.

Operational acceptance means the intended replication partners succeed for every relevant naming context; the object/attribute is verified on the destination; event logs do not show recurring failures; the replication schedule and site topology match the design; and the remediation does not depend on repeated manual forcing. Monitor daily or use a supported health system to alert on failure and delta thresholds. Reassess after DC promotion or demotion, site changes, firewall redesign, DNS migration, forest functional-level changes, and network outages.

Related:

Sources:

Comments