Active Directory Replication and topology
Sites, subnets, and replication topology
Check site membership, site links, KCC connections, ISTGs, and bridgehead assumptions.
Sites influence more than replication
Subnet objects map client addresses to AD sites. That mapping affects DC location and services such as DFS referrals, so a missing subnet can produce remote logons or file access even while replication is healthy.
From the affected client:
nltest /dsgetsite
nltest /dsgetdc:contoso.com
Compare the client’s site and returned DC’s site with the intended network location. Inspect Netlogon event 5807 and %windir%\debug\netlogon.log on DCs for clients whose addresses cannot be mapped. NAT and VPN address pools deserve particular attention.
Collect the topology
Using the ActiveDirectory module:
Get-ADReplicationSite -Filter * | Select-Object Name
Get-ADReplicationSubnet -Filter * -Properties Site, Location |
Select-Object Name, Site, Location
Get-ADReplicationSiteLink -Filter * -Properties ReplicationSchedule |
Select-Object Name, Cost, ReplicationFrequencyInMinutes,
SitesIncluded, ReplicationSchedule
Look for subnets mapped to the wrong site, sites missing from links, and identical costs where the network has a clear preferred route. A site without a DC can be intentional; it still needs correct subnet mapping and a sensible plan for finding services. Site-link costs can affect DC Locator and DFSN as well as replication.
Connection objects are inbound
A connection beneath DC1’s NTDS Settings object describes replication into DC1 from a source. A connection object is not a tunnel and does not change router or firewall behavior.
repadmin /showconn DC1 /verbose
repadmin /showrepl DC1 /all /verbose
repadmin /failcache DC1
The KCC generates connections from the configured topology and adjusts them as conditions change. It doesn’t manage manually created or administratively modified connections in the same way. Keep a note of why those objects exist; they aren’t automatically wrong. See AD replication concepts.
ISTG and bridgeheads
For writable DCs in a site, a selected intersite topology generator calculates the site’s intersite topology. Each RODC’s KCC instead acts as an ISTG for itself. This distinction matters when interpreting the site setting in a branch containing only RODCs. See the ISTG selection specification. Bridgeheads are the DCs selected to participate in intersite replication connections.
repadmin /istg * /verbose
repadmin /bridgeheads * /verbose
Check preferred bridgeheads alongside firewall rules. Restricting the candidates can prevent failover, but the restriction may be part of the firewall design. Understand that before removing it. Compare different DCs’ views if configuration replication itself is suspect.
Bridge all site links expresses reachability
Automatic bridging assumes transitive connectivity across site links. In a fully routed network this generally saves manual work. In a network with restricted reachability, the design may need explicit bridges so the KCC does not select an impossible direct connection. A bridge does not force the intermediate site’s DC to relay the data.
Record why BASL was changed, the intended routes for each naming context, and where schedules need to overlap. Revisit that choice when the network changes, rather than switching it to tidy up a diagram.
Recalculation and convergence take time
Changes topology calculation: repadmin /kcc DC1 requests immediate KCC recalculation on that DC. It does not repair DNS, open firewall ports, or prove that the resulting connections work.
After a topology change, give configuration replication and the affected components time to pick it up. Then recheck each required naming context, selected partners, and convergence time. “Never replicated” on a new connection describes that connection’s history; it doesn’t mean the DC has never replicated.
Read the site object’s settings from an explicit DC
$dc = 'DC1.contoso.com'
$config = (Get-ADRootDSE -Server $dc).configurationNamingContext
Get-ADObject -Server $dc -SearchBase "CN=Sites,$config" `
-LDAPFilter '(objectClass=nTDSSiteSettings)' `
-Properties interSiteTopologyGenerator, options |
Select-Object DistinguishedName, interSiteTopologyGenerator, options
This reads the configuration copy on $dc, including the selected writable ISTG’s NTDS Settings DN and raw option bits. If the selection looks inconsistent, compare another DC. ADSI Edit and Sites and Services each show a particular replica’s view. The ISTG specification explains the difference between writable-site selection and RODC behavior.
Schedule, frequency, and notification differ
A site link’s schedule describes when it is available. Its replication interval describes periodic attempts within that availability. Costs select preferred routes. None of those changes the physical route packets take. Enabling intersite change notification can reduce latency but does not remove transport failures or turn a partial network into a fully routed one.
Get-ADReplicationSiteLink -Identity 'Sydney-Melbourne' -Server $dc `
-Properties ReplicationSchedule, options |
Format-List Name, Cost, ReplicationFrequencyInMinutes,
ReplicationSchedule, SitesIncluded, options
Check the actual option bits and preserve existing values when planning a change. Replacing the entire options field with a single value can erase another option. Microsoft’s site-link cmdlet documents notification and schedule controls; its examples need adaptation when other option bits are already in use.
A site link can include more than two sites
Putting every site into one default link does not force a full mesh of DC connections. The KCC constructs an intersite topology for the relevant partitions from the available connectivity model. If the real network is hub-and-spoke, one broad equal-cost link can permit a selection that does not match that layout.
Model reachability and cost together, and verify the resulting connections. Different domains and application partitions can produce different bridgehead requirements because the chosen DCs must host the data being replicated. The replication concepts guide describes connections, site links, and transitivity.
Separate site mapping from a caller’s constraints
A client can be mapped correctly yet use a remote DC because its site has no DC for the requested domain, no writable DC for the operation, or no suitable GC. Check the requested capability and DNS response before adding subnets or moving DC objects.
“Try Next Closest Site” uses site-link cost when local service is unavailable; automatic site coverage and the caller’s flags also influence discovery. Next-closest-site guidance explains why changing costs can affect clients as well as replication. Include representative DC Locator checks in topology-change validation.
Inspect the address the DC actually mapped
A subnet object maps addresses to sites; it doesn’t configure a router or DHCP scope. Overlapping AD subnets can be intentional: a more specific prefix can assign a branch differently from an aggregate. Check the site returned for a real client address before treating an overlap as an error. Include IPv6, VPN pools and NAT addresses visible to DCs, and compare configuration replicas after a recent change. The subnet-object specification defines address/name constraints; DsAddressToSiteNamesEx can return the subnet used for a mapping.
During the LDAP ping, the DC normally starts with the client’s socket address. Protocol/version-specific fallback can resolve the supplied client name if that address cannot be mapped. Consequently the address in a client screenshot is not always the address the receiving DC used. See the LDAP-ping response algorithm.
For unmapped clients, event 5807 and NO_CLIENT_SITE lines in the DC’s existing %windir%\debug\netlogon.log / .bak provide names and addresses. Preserve the logs before rotation. Historical entries can reflect a retired device, an old VPN range, or an already corrected mapping; establish when they were written before creating subnets. Unmapped requests can also consume name-resolution/ATQ work, so this is a potential performance input rather than merely a cosmetic site-design finding. Microsoft’s delayed-response analysis explains the branch. Do not apply its old thread-pool workaround before establishing the actual load and current build behavior.
For healthy-looking configuration with missing per-NC agreements, disabled connection translation or constrained bridgeheads, continue with topology diagnostics.