Active Directory Sites and Services Explained (Windows Server 2025)

10 min read
TL;DR
  • Single office, single subnet: one site, nothing to configure. Default setup is correct. A new forest always includes DEFAULTIPSITELINK – it just has no meaningful intersite role with one site.
  • Multiple offices with a WAN between them: each office needs its own site, subnets assigned, and a site link with defined cost and interval.
  • Clients prefer DCs in their own site – but only if subnet assignments tell AD which site the client belongs to. Missing mappings show up as NO_CLIENT_SITE entries in Netlogon.log and NETLOGON Event ID 5807, not Event ID 1311.
  • Site links describe logical replication paths for the KCC. They do not choose the physical MPLS, broadband, or 4G circuit – that is handled by routing, SD-WAN, or VPN.
  • After any AD Sites and Services change: verify with nltest /dsgetsite, nltest /dsgetdc:<domain> /force, repadmin /replsummary, and repadmin /showrepl before assuming it worked.
AD Sites and Services two-site topology - HQ and London connected by site link with cost 100

Most single-office deployments never open AD Sites and Services. The default configuration – one site, the built-in DEFAULTIPSITELINK – handles everything automatically, and that is correct. The problem starts when a second office comes online.

Without correct site and subnet configuration, clients in the branch authenticate against DCs in headquarters, crossing the WAN for every Kerberos ticket. Replication runs on no schedule. New DCs land in the site of their replication source instead of their own subnet’s site, and stay there until someone investigates. None of this produces an immediate error – just slow logins and replication lag that gets blamed on the WAN link before anyone checks the topology.

AD Sites and Services is the MMC console where you define the physical-to-logical mapping that controls replication behavior and DC selection. This article covers the components, the configuration decisions, and the verification workflow.

What Is a Site in Active Directory?

In Active Directory, a “site” is a named group of well-connected IP subnets – typically a physical office or datacenter with fast internal connectivity. The word “site” has nothing to do with the domain or forest structure. A single domain can span multiple sites, and a single site can contain DCs from multiple domains.

The distinction that matters operationally: intrasite replication is automatic and triggered by changes, with no configurable schedule. Intersite replication is controlled by site links you define – with explicit cost and interval values. Without site configuration, AD treats everything as intrasite, which is correct for one office and wrong when a WAN link enters the picture.

A new forest always includes a default IP site link named DEFAULTIPSITELINK. In a single-site environment it exists but has no meaningful intersite role – it only matters once you define a second site. For a single-office environment with one contiguous IP range: one site, no action required. Creating additional sites without a WAN boundary adds administrative overhead with no operational benefit.

AD Sites and Services Components

ComponentWhat it controls
SiteNamed logical grouping of subnets (for example, “HQ” or “London”)
SubnetIP range associated with a site – the key to DC Locator behavior
Site LinkLogical replication path between two or more sites – defines cost and replication interval
Site Link BridgeControls transitive replication paths; “Bridge all site links” is enabled by default and assumes fully routed IP connectivity between all sites
NTDS Site SettingsPer-site KCC configuration; rarely modified directly

The KCC (Knowledge Consistency Checker) runs on every DC and automatically builds the replication topology based on site and site link configuration. It recalculates every 15 minutes by default. Changes to AD Sites and Services affect replication topology on the next KCC cycle. Subnet mapping and DC Locator behavior also depend on AD replication completing and on cached locator data – not every change simply requires waiting 15-30 minutes. In practice, expect 15-30 minutes before replication topology changes are visible, but verify explicitly rather than assuming.

This timing catches operators off guard. You create a site, assign subnets, configure a site link – and replication does not change immediately. The correct response is to wait for the next KCC cycle, then verify with the commands in the verification section below.

Global Catalog Placement in Multi-Site Environments

In multi-site deployments, consider whether each site needs a local Global Catalog server. The decision depends on several factors: number of users at the site, WAN reliability and latency to the nearest existing GC, whether applications require local GC access (Exchange or similar on-prem workloads), and whether users roam between sites frequently. For smaller branch offices with a reliable WAN and fewer than 20-30 users, Universal Group Membership Caching is an alternative – it caches group membership locally without requiring a full GC. For branch offices with more than a handful of users or an unreliable WAN connection, a local DC promoted with the Global Catalog role is usually the cleaner choice.

How DC Locator Uses Site Information

DC Locator is the process clients use to find a domain controller for authentication. Site configuration is what makes DC Locator prefer local DCs over remote ones.

When a client starts the logon process, it determines its site based on the IP subnet assigned in AD Sites and Services. The client then:

  1. Queries DNS for a DC with a site-specific SRV record matching its site.
  2. Attempts authentication against a local DC from that site.
  3. Falls back to any available DC only if no local DC is reachable or no site match exists.

The site is not manually configured on clients – it is calculated automatically from the client IP address against the subnet objects stored in AD. This is why subnet assignments matter more than site names. A correctly named site with no subnets assigned does nothing useful for DC Locator.

Site coverage handles the edge case where a site has clients but no DC. AD automatically assigns the nearest DC from another site to service authentication requests for that site. Site coverage prevents authentication failures but should not be treated as a design strategy – large branch offices benefit from a local DC regardless.

When to Create Additional Sites

Create a new site when a WAN link separates DCs or clients from the main office. Do not create sites for VLANs on the same LAN – VLANs are routing boundaries, not replication boundaries. A DC on VLAN 20 and a DC on VLAN 10 connected by a Layer 3 switch on gigabit links do not need separate sites in AD Sites and Services.

ScenarioCorrect configuration
Single office, multiple VLANsOne site – no additional configuration
Head office and branch over MPLSTwo sites, one site link
Head office and branch with MPLS plus 4G failoverTwo AD sites and one logical site link; configure physical path selection in routing, SD-WAN, or VPN – site-link cost does not choose which physical circuit carries the packets
Three offices, hub-and-spoke WANThree sites, site links matching the WAN topology

Configuring AD Sites and Services

Create a New Site

# Create the new site New-ADReplicationSite -Name "London" # Verify Get-ADReplicationSite -Filter *

The site appears in the AD Sites and Services console immediately. No replication traffic moves through it until subnets and a site link are configured.

Assign Subnets to Sites

# Assign subnet to the new site New-ADReplicationSubnet -Name "10.1.0.0/24" -Site "London" # Assign HQ subnet explicitly if not already defined New-ADReplicationSubnet -Name "192.168.1.0/24" -Site "Default-First-Site-Name" # Verify assignments Get-ADReplicationSubnet -Filter * | Select-Object Name, Site

Every subnet that contains DCs or clients must be assigned to a site. Unassigned client subnets do not cause immediate authentication failures. Instead, clients cannot be mapped to an AD site, so DC Locator falls back to any available DC regardless of location. Check Netlogon.log for NO_CLIENT_SITE entries and review NETLOGON Event ID 5807 for accumulated unmapped client addresses. Event ID 1311 is different – it indicates the KCC cannot build or maintain a valid replication topology, typically due to disconnected site links, offline DCs, or misconfigured bridgeheads.

Failure scenario

A branch office DC is promoted before its subnet is added to AD Sites and Services. The DC lands in the site of its replication source – which may be the HQ site or Default-First-Site-Name, not the intended branch site. Clients in the branch have no site match, so DC Locator sends authentication requests to both branch and HQ DCs without preference. On a congested WAN link, logins become noticeably slow during peak hours. Netlogon.log on the branch DC accumulates NO_CLIENT_SITE entries, and NETLOGON Event ID 5807 appears for unmapped client addresses. The fix – adding the missing subnet and moving the DC to the correct site – takes minutes. Diagnosing the cause typically takes much longer.

Configure Site Link Cost and Replication Interval

# Create a site link between HQ and London New-ADReplicationSiteLink -Name "HQ-London" ` -SitesIncluded "Default-First-Site-Name","London" ` -Cost 100 ` -ReplicationFrequencyInMinutes 180 # Verify Get-ADReplicationSiteLink -Filter * | Select-Object Name, Cost, ReplicationFrequencyInMinutes

Site-link cost is a relative value – the default is 100. Lower cost means the KCC prefers that logical replication path. Cost is useful when AD has a choice between different topology paths, such as London-Frankfurt directly versus London-HQ-Frankfurt. It does not select which physical circuit carries packets between the same two endpoints – that is determined by routing, SD-WAN, or VPN configuration. The cost values below are illustrative and relative to your specific topology.

Link typeIllustrative cost
LAN or primary MPLS100
Secondary MPLS or stable broadband150-200
Variable-quality broadband200-300
4G or unreliable backup path400-500

Replication interval: the default 180 minutes means password resets and group membership changes can take up to 3 hours to reach branch DCs. For most SMB environments this is acceptable. If same-day propagation matters, lower to 60 minutes. Do not go below 15 minutes – that is the protocol minimum. A shorter interval on an unreliable WAN exposes existing replication problems more frequently; it does not cause them.

Verifying AD Sites and Services Changes

AD Sites and Services changes do not self-report success. Run these checks after any topology change.

Post-configuration verification workflow
  1. Confirm which site the local DC is in: nltest /dsgetsite – run directly on the DC. Output should name the site you assigned it to.
  2. Force a DC Locator query: nltest /dsgetdc:<domain> /force – clears the cached result and returns the DC found after a fresh lookup. Confirm the DC is in the expected site.
  3. Check replication health summary: repadmin /replsummary – fastest way to identify failed replication partners before reviewing detail.
  4. Check detailed replication: repadmin /showrepl – intersite replication should show expected partners and a recent last-replication timestamp.
  5. Check for replication failures scoped to the site: Get-ADReplicationFailure -Scope Site -Target "London" – any errors indicate a misconfigured site link or unreachable partner DC.
  6. Verify DC placement: Get-ADDomainController -Filter * | Select HostName,Site,IPv4Address – confirm each DC is in the site that matches its subnet.

If nltest /dsgetdc returns a DC in the wrong site, start with subnet assignment. Check Netlogon.log for NO_CLIENT_SITE entries before investigating site link configuration – the subnet is almost always the issue.

Quick Troubleshooting Reference

SymptomLikely causeFirst check
Client selects a remote DCMissing or incorrect subnet mapping, cached DC Locator result, no local DCnltest /dsgetsite, then nltest /dsgetdc:<domain> /force
New DC appears in unintended siteNo matching subnet during promotion; replication-source site was used insteadGet-ADDomainController -Filter * | Select HostName,Site,IPv4Address
NO_CLIENT_SITE in Netlogon.log or NETLOGON Event ID 5807Client IP range not mapped to an AD subnetAdd or correct the subnet object in AD Sites and Services
Event ID 1311 in Directory Service logKCC cannot construct a complete replication topologyCheck site-link connectivity, DC availability, and repadmin /replsummary
Replication uses an unintended logical pathSite-link membership or cost does not match the available topologyGet-ADReplicationSiteLink -Filter * -Properties *
Physical traffic uses 4G instead of MPLSRouting, SD-WAN, VPN, or WAN-edge path selection – not AD site-link costInspect routing tables and WAN failover policy
Password changes take hours at branchSite-link replication interval, multi-hop topology, or replication failurerepadmin /showrepl and site-link interval settings
Event 1925 or 2087Replication connectivity or DNS resolution failureResolve the specific error; verify DNS, RPC, firewall, and DC reachability

Common Mistakes

All DCs land in the default site after adding a branch. This happens when the branch DC is promoted before its subnet is configured in AD Sites and Services. A DC promoted without a matching subnet lands in the site of its replication source DC – not automatically in Default-First-Site-Name, but wherever the source DC lives. Fix: add the subnet, then move the DC to the correct site using the console or Move-ADDirectoryServer. Do not leave it – replication and DC Locator behavior will be wrong for every client in that subnet.

Subnet ranges overlap between sites. If 10.1.0.0/16 is assigned to HQ and 10.1.5.0/24 is assigned to London, AD matches the more specific subnet. Overlapping definitions work but create confusion and future misassignment risk. Keep subnet definitions clean and non-overlapping.

Site link cost left at 100 for every link. With two site links at equal cost, the KCC picks arbitrarily. On a hub-and-spoke topology this can route replication over a slow branch link instead of the MPLS backbone. Set cost values deliberately based on relative link quality and topology.

Event IDs 1925 and 2087 indicate failed replication connectivity or DNS resolution failure – they are not caused by an aggressive replication interval. A shorter interval exposes an existing problem more frequently. The underlying issue is DNS, RPC, firewall, or DC reachability. Diagnose the actual connectivity failure rather than raising the interval to reduce symptom frequency. For replication failures in depth, see Active Directory replication troubleshooting.

FAQ

Do I need to configure AD Sites and Services for a single-office setup?

No. The default single-site configuration is correct. DEFAULTIPSITELINK exists in every new forest but has no meaningful role until a second site is created. Adding sites without a WAN boundary creates administrative overhead with no operational benefit.

What happens if I don’t assign subnets to sites?

Clients cannot determine which site they belong to, so DC Locator falls back to any available DC regardless of location. On a WAN-connected branch, authentication crosses the WAN unnecessarily. Check Netlogon.log for NO_CLIENT_SITE entries and NETLOGON Event ID 5807 for unmapped client addresses. Event ID 1311 is a separate issue – it indicates the KCC cannot construct a complete replication topology and is not triggered by missing subnet mappings.

How long do AD Sites and Services changes take to take effect?

Replication topology changes take effect after the KCC recalculates (default every 15 minutes) and the updated topology propagates. Subnet mapping and DC Locator also depend on AD replication completing and cached locator data expiring – not every change is simply a 15-30 minute wait. Verify explicitly after each change rather than assuming.

What is the minimum replication interval between sites?

15 minutes. The protocol does not support lower values.

What is site coverage in Active Directory?

If a site has clients but no DC, AD automatically assigns the nearest DC from another site to handle authentication for that site. Site coverage prevents authentication failures in this scenario but is not a design strategy – a large branch office should have a local DC.

Can a site link include more than two sites?

Yes. A site link can include multiple sites, and all listed sites replicate with each other at the defined cost and interval. A single multi-site link creates any-to-any replication connectivity among all listed sites – closer to full-mesh than hub-and-spoke. For a true hub-and-spoke topology where branches should replicate only through the hub, configure separate per-pair site links (branch-to-hub) rather than one multi-site link covering all locations.

Why do password changes sometimes fail at branch offices even when replication looks healthy?

The PDC Emulator receives password changes preferentially, ahead of normal replication. When a user changes their password, the change reaches the PDC Emulator immediately. If a branch DC rejects authentication with a recently changed password, it checks the PDC Emulator before generating a final failure. In a multi-site environment where the PDC Emulator is in a remote site, this cross-site check adds latency. If the PDC Emulator is unreachable from the branch DC, recent password changes may fail until normal replication completes.

Final Thoughts

For most SMB deployments, AD Sites and Services is a one-time configuration task. Add the sites, assign the subnets, set site link costs – and it runs without further intervention. The fundamental concepts apply to all currently supported Windows Server versions, not only 2025.

The operators who skip this step are not making a visible mistake on day one. They are creating a diagnostic problem for the day a branch office goes live, logins slow down during peak hours, and nobody connects slow authentication to AD topology. The subnet assignment step takes two minutes. Diagnosing the root cause after the fact consistently takes much longer.

AD Sites and Services is the physical-to-logical mapping that the rest of the AD infrastructure depends on for efficient operation. For the domain and forest structure that sites sit within, see Active Directory structure explained. For replication failures after the topology is configured, the Active Directory replication troubleshooting guide covers diagnostic workflows in detail. For the full technical reference on KCC topology building, Microsoft’s Active Directory Replication Concepts is the authoritative source. The Understanding Active Directory Site Topology documentation covers site link bridge behavior and transitive replication paths. The Event ID 1311 troubleshooting guide covers KCC topology failures in detail.