Diagnose the replication topology

A topology exists for each partition

Start with the naming context that is missing updates. A diagram connecting every site can still leave one application partition disconnected. If Sydney and Perth hold ForestDnsZones but the intermediate site’s DCs do not, that intermediate DC cannot relay those DNS objects. The connectivity model must permit a direct eligible partnership or another path through replicas that actually hold the partition.

Record source and destination replica types as well as their sites. A GC’s partial domain replica and an RODC’s full read-only replica have different source-selection rules. Microsoft’s connection-translation specification defines when a connection implies a usable source for a particular NC.

Get-ADRootDSE -Server 'DC1.contoso.com' |
    Select-Object -ExpandProperty namingContexts
Get-ADReplicationPartnerMetadata -Target 'DC1.contoso.com' `
    -Partition '*' -PartnerType Inbound |
    Select-Object Partition,Partner,LastReplicationSuccess,LastReplicationResult

Repeat on the intended partners. Another DC’s configuration copy may describe a server whose actual state has changed, so query the server directly where possible. Keep unreachable targets in the results.

Distinguish design, connections and agreements

One connection can support several NCs. You’ll still need to check that each expected agreement exists and has completed initial synchronization. repsFrom is local replication state, rather than a normal replicated configuration object. The KCC architecture reference explains the difference.

repadmin /showconn DC1 /verbose
repadmin /showrepl DC1 /all /verbose
repadmin /failcache DC1

Compare the fromServer, enabled state, schedule, generation/ownership options and NC reasons with the actual /showrepl entries. “Never” is the relationship’s history; investigate whether it is new, cannot initialize, or repeatedly loses priority.

Inspect disabled translation and replication

Read the destination’s settings from that DC:

$dc = 'DC1.contoso.com'
$dsa = (Get-ADDomainController -Identity $dc -Server $dc).NTDSSettingsObjectDN
$settings = Get-ADObject -Server $dc -Identity $dsa -Properties options
$bits = [int]$settings.options
[pscustomobject]@{
    DC = $dc
    RawOptions = $bits
    InboundDisabled = ($bits -band 2) -ne 0
    OutboundDisabled = ($bits -band 4) -ne 0
    ConnectionTranslationDisabled = ($bits -band 8) -ne 0
}

These flags restrict different things. Bit 0x8 prevents connection objects from being translated into repsFrom agreements. Left behind after a failed recovery, it can explain why a connection looks right but never becomes a working relationship. The inbound/outbound disable flags have their own forced-request exceptions. Check why a flag was set and the recovery history before clearing it. The nTDSDSA definition documents these bits; options on another object class means something different.

Transport options can override a site-link schedule

$config = (Get-ADRootDSE -Server $dc).configurationNamingContext
Get-ADObject -Server $dc `
    -Identity "CN=IP,CN=Inter-Site Transports,CN=Sites,$config" `
    -Properties options | Select-Object DistinguishedName,options

On the IP transport, 0x1 means ignore site-link schedules and treat availability as always on. 0x2 means explicit site-link bridges are required for transitivity. These are transport-wide controls, unlike a particular site’s KCC options or a particular link’s notification/compression flags. See the IP transport definition.

When actual traffic contradicts a schedule, inspect this layer, the generated connection and the effective agreement. A manual connection or user-owned schedule can also preserve behavior that differs from the latest site-link design.

Evaluate a transitive path as a whole

Across a combined site-link path, costs add up, the least frequent link limits the replication interval, and availability comes from the overlap between schedules. Special options also combine along the route. A cheap path is no use if its schedules never overlap. Notification on one part of a path doesn’t mean notification works across the whole path. Site-graph concepts and the topology reference’s site-link discussion describe how these combine.

BASL models transitive reachability. It does not make an intermediate DC a packet router or open its firewall. Check the actual destination-to-source RPC path selected by the generated connection. The KCC can create a candidate before discovering that the network prevents its use.

Test bridgehead failure as an outage scenario

Inspect preferred bridgeheads per partition, not just per site. A surviving DC is useful only if it is an eligible source for the required NC. When valid preferred candidates for a partition exist but all are unavailable, do not assume the KCC will automatically choose an ordinary DC outside that restricted set. The bridgehead selection reference describes that constraint.

Failover takes failure detection, candidate selection, configuration replication and successful initialization of the replacement relationship. Losing a whole hub is different from losing one DC: several unusable candidates can delay the alternate route. Test the failure case you need to survive, rather than assuming failover at the next 15-minute KCC run.

Before introducing manual connections, document their scope, schedules, owner and removal condition. A temporary diagnostic connection can establish whether an intended source works; retaining it permanently changes topology management. repadmin /kcc DC1 requests recalculation, so preserve the original state before using it. Verify resulting agreements and the disputed data afterward. Use convergence measurements to establish delivery rather than counting connection objects.