Active Directory works fine in a single office without anyone touching Sites and Services. Add a second location across a WAN link, though, and the picture changes. Without site configuration, a user in your branch office might authenticate against a domain controller back at headquarters, pulling logon and Group Policy traffic across an expensive, slow link — and you’d never get an error telling you why things feel sluggish.
Sites and Services is where you describe your physical network to Active Directory so it can make smart decisions: which DC a client should use, and how replication traffic should flow between locations. This guide explains the moving parts — sites, subnets, site links, and the KCC — and how to set them up for a multi-office network.
The core idea: physical vs logical
Active Directory has two structures that are easy to confuse. The logical structure is domains, OUs, and the directory tree — it has nothing to do with geography. The physical structure is sites and subnets, and it mirrors your actual network: buildings, data centers, and the links between them.
Sites and Services is the tool for the physical side. You use it to tell AD three things:
- Which IP subnets belong to which physical location (the subnet-to-site mapping).
- How those locations connect, and how good each connection is (site links).
- Where the domain controllers physically live (server objects in each site).
Get those right and AD handles the rest: clients find a nearby DC, and replication respects your WAN.
Sites and subnets
A site is a collection of well-connected subnets — usually everything in one physical location with fast LAN-grade bandwidth between the machines. A new forest starts with one site, named Default-First-Site-Name, and every DC lands in it until you create more.
A subnet object maps an IP range to a site. This is the piece that makes everything else work. When a client starts up, it looks up its own IP against the defined subnets to learn which site it’s in, then asks for a domain controller in that site.
The practical rule: every IP range that hosts clients or servers should have a matching subnet object pointing at the correct site. Miss one and the devices on it get unpredictable DC selection.
Site links and how replication crosses the WAN
A site link connects two or more sites and tells AD that replication can travel between them. Each link has properties that control how that replication behaves over the connection:
Site link properties
| Cost | A relative weight for the link. Lower cost = preferred path. Use it to make replication favor a fast link over a slow backup link. |
|---|---|
| Replication interval | How often replication occurs over the link. Default is 180 minutes; the minimum is 15. |
| Schedule | The windows during which replication is allowed. You can block replication during business hours on a constrained link. |
| Transport | IP (RPC) for almost all cases. SMTP is legacy and rarely used. |
The default DEFAULTIPSITELINK connects everything initially. In a real multi-office design you create named links that match your actual WAN topology and set cost and interval to reflect each link’s speed and reliability.
Intra-site vs inter-site replication
How replication behaves depends entirely on whether it’s happening within a site or between sites. The difference is deliberate.
Within a site, AD assumes bandwidth is plentiful. Replication is triggered by change notification almost immediately, and the data isn’t compressed because CPU is more expensive than the bandwidth you’d save.
Between sites, AD assumes the link is slower or costs money. Replication is compressed to reduce traffic, and it only happens on the site link’s schedule and interval — by default every 180 minutes. That means a password change at one office can take time to reach another, which is normal and by design (urgent changes like account lockouts and password resets are handled specially).
Intra-site vs inter-site replication
| Trigger | Intra-site: change notification (near-immediate). Inter-site: scheduled interval. |
|---|---|
| Compression | Intra-site: none. Inter-site: compressed to save WAN bandwidth. |
| Default frequency | Intra-site: seconds after a change. Inter-site: every 180 minutes. |
| Topology builder | Both built by the KCC; inter-site connections coordinated by the ISTG. |
The KCC: who builds the topology
You rarely create replication connections between domain controllers by hand. The Knowledge Consistency Checker (KCC) does it for you. It’s a process running on every DC that builds and maintains the connection objects that define the replication topology, recalculating when DCs are added, removed, or change sites.
For inter-site replication, one DC per site takes on the role of Inter-Site Topology Generator (ISTG), which coordinates the connections that cross site links. The KCC and ISTG together keep replication paths consistent so that, in a healthy environment, every DC eventually receives every change.
The takeaway for day-to-day work: define your sites, subnets, and links correctly, and let the KCC build the connections. Manually created connection objects are for specific situations, not normal operation. If replication isn’t flowing the way you expect, the fault is usually in the topology you defined, not the KCC’s logic.
Setting up a two-office network: a worked example
Say you have a head office (HQ) on 10.10.0.0/16 and a branch on 10.20.0.0/16, connected by a single WAN link, with a domain controller in each. Here’s the configuration in order:
- Create the sites. In Active Directory Sites and Services, rename
Default-First-Site-NametoHQ(or create a newHQsite) and create a second site namedBranch. - Create subnet objects. Add
10.10.0.0/16mapped toHQand10.20.0.0/16mapped toBranch. - Move the domain controllers. Make sure each DC’s server object sits in the correct site. AD often places a DC in the right site automatically based on its IP, but verify it.
- Create the site link. Under Inter-Site Transports > IP, create a link named
HQ-Branchcontaining both sites. Set the cost and replication interval to match the WAN link’s speed and your tolerance for replication lag. - Verify. Confirm clients in each office are using their local DC.
You can confirm a machine’s site assignment from any domain member:
nltest /dsgetsiteAnd see which DC a client is actually using:
nltest /dsgetdc:yourdomain.localIf a branch client reports the HQ domain controller, recheck your subnet mapping — that’s almost always the cause.
Multi-office Sites and Services checklist
- One site per physical location with distinct, good-bandwidth networks
- Every client and server subnet mapped to the correct site
- Site links reflect the real WAN topology, with cost set per link speed
- Replication interval and schedule tuned to the link, not left at random
- Each DC's server object is in the right site
- nltest /dsgetdc confirms clients use a local DC
When does a branch office need its own DC?
A local domain controller speeds up authentication and keeps the office working if the WAN link drops. But every DC is also a copy of your directory that has to be physically secured and patched. The decision comes down to the link and the location:
- Fast, reliable link, secure central site — a branch can often authenticate against a central DC without a local one.
- Slow or unreliable link — put a DC in the branch so logons and Group Policy don’t depend on the WAN.
- Local DC needed but weak physical security — use a read-only domain controller (RODC), which holds a filtered set of credentials and can’t be written to, limiting the damage if the box is stolen.
Whatever you decide, keep each DC’s DNS configuration correct, because site-aware DC location depends on healthy DNS. Our guide on the best DNS settings for domain controllers covers that side, and if replication between offices stops, the error 1722 walkthrough is the place to start.
Wrapping up
Active Directory Sites and Services is how you teach AD about the real, physical shape of your network. Define a site per location, map every subnet to its site, connect them with site links that reflect your WAN, and let the KCC build the replication topology. Done right, clients authenticate locally and replication respects your bandwidth. Skip the subnet mapping and you get cross-WAN logons and confusing performance complaints with no obvious error to chase.
