Active Directory Sites and Services: What It Does and Why It Matters

Sites and Services is the console most administrators open once, find confusing, and never return to. It’s also the reason clients in a branch office authenticate against a domain controller three hundred miles away, and why logons there take forty seconds.

It does two jobs: it decides how domain controllers replicate with each other, and it tells clients which domain controller is nearest. The second one is where the visible pain lives.

Why clients pick the wrong domain controller

When a client starts up it asks DNS for a domain controller. DNS answers based on the client’s IP address and the subnet-to-site mapping in Active Directory. If the client’s subnet isn’t defined anywhere, AD has no idea where it is, so it hands back any domain controller, potentially one across a WAN link.

The symptom is slow logons, slow Group Policy processing and odd authentication delays in one location while everything else is fine. The fix is trivial once you know:

# Which DC is this client actually using?
nltest /dsgetdc:yourdomain.com

# What site does the client think it is in?
nltest /dsgetsite

# Find subnets that are not mapped to any site
Get-ADReplicationSubnet -Filter * | Select-Object Name, Site |
    Where-Object { -not $_.Site }

There’s also a log that tells you outright. Domain controllers record unmapped subnets in the Netlogon.log file:

findstr /c:"NO_CLIENT_SITE" C:\Windows\debug\netlogon.log

Every line there is a client whose subnet you haven’t defined. On most networks that have grown organically, this file is longer than people expect.

The three objects that matter

Adding a subnet properly

# Or in PowerShell
New-ADReplicationSubnet -Name '10.20.30.0/24' -Site 'Manchester'

Site links and cost

Site links define which sites replicate with which, how often, and how attractive the path is. Cost is the deciding factor when there’s more than one route. Lower wins.

A sensible convention is to base cost loosely on bandwidth, so a fast link is cheaper than a slow one and traffic naturally prefers it:

Get-ADReplicationSiteLink -Filter * |
    Select-Object Name, Cost, ReplicationFrequencyInMinutes, SitesIncluded

# Adjust a link
Set-ADReplicationSiteLink -Identity 'London-Manchester' -Cost 200 -ReplicationFrequencyInMinutes 30

Default replication frequency between sites is 180 minutes. On decent modern links there’s rarely a reason to leave it that high: 15 to 30 minutes is common and costs very little bandwidth.

Leave the KCC alone

The Knowledge Consistency Checker builds and maintains the replication topology automatically, and it’s genuinely good at it. Manually created connection objects stop it adapting when a domain controller fails, which is precisely when you want it adapting.

Check replication health rather than hand-building topology:

repadmin /replsummary
repadmin /showrepl
dcdiag /test:replications

Glossary

Frequently asked questions

Why are logons slow in one office but fine elsewhere?

Almost always a missing subnet definition. Clients there can’t be located, so they authenticate against whichever DC DNS returns, often across a WAN. Check netlogon.log for NO_CLIENT_SITE entries.

Do I need a site for every office?

Only if it has its own domain controller, or if you want clients there to prefer a specific DC. A small branch on a fast link can sit in the same site as head office.

Should I create connection objects manually?

No, in almost all cases. The KCC adapts to failures; manual objects don’t. Only override it if you have a specific, documented reason.

How often should sites replicate?

The 180-minute default is very conservative. On modern links 15-30 minutes is typical and the bandwidth cost is small.

What happens if two sites have equal cost?

AD picks one, and you lose predictability. Give links deliberately different costs so the preferred path is unambiguous.

Disclosure: this post may contain affiliate links. If you buy through one of them, we may earn a small commission at no extra cost to you. We only recommend products we’ve tested or genuinely rate.