An Active Directory site is a logical object that represents a well-connected portion of your physical network, normally a single geographic location such as a data center or branch office. AD has no inherent sense of geography, so sites are how you teach the directory where things physically are and how expensive it is to talk between them.

The building blocks. A site is defined by the IP subnets mapped to it, the domain controllers placed in it, and the site links that connect it to other sites. A subnet belongs to exactly one site; a site can own many subnets. Every DC is assigned to the site whose subnet contains its IP address.

Two jobs sites do. First, they govern replication: traffic inside a site is immediate and uncompressed, while traffic between sites is scheduled, compressed, and routed along the site links you control. Second, they steer clients: when a workstation logs on, the DC Locator hands it the site-aware SRV records for its own subnet, so it authenticates against a local DC instead of one across the WAN.

Why it matters. Forget to map a branch subnet and its clients fall back to the full DC list, often authenticating over a slow WAN link. That is the number-one cause of "logons are slow at the branch."

A subnet object is the bridge between an IP range and a site. Administrators must register each subnet and associate it with the site that owns it. Until that mapping exists, AD cannot tell which clients are "local" to which domain controllers.

How clients use it. When a client boots, the DC Locator process compares the client's IP against the registered subnets, finds the matching site, and returns the site-specific SRV records so the client binds to a DC in its own location. With no matching subnet the client receives the full list of DCs and may authenticate against any one of them, frequently the wrong one across a WAN link.

The relationship. One subnet maps to exactly one site, but a site can hold many subnets. Branch subnets are the ones most often forgotten, which is why "no client site" events in the netlogon log are a classic branch-office symptom.

Subnet-to-site mapping is not a cosmetic detail. It is the data the DC Locator relies on to keep authentication, policy, and file access local. Get it wrong and the symptoms surface far from the cause.

What breaks when a subnet is unmapped. Clients pick a random domain controller, often one across a slow WAN link, so logons drag. Site-linked Group Policy and the site's DFS referrals resolve to the wrong location. Even Exchange and other site-aware services route clients to distant servers.

The fix is registration discipline. Every production subnet should be registered to its site before clients live there. Treat a new branch network as incomplete until its subnet object exists, and audit the netlogon log periodically for clients that found no site.

A site link is the object that says two or more sites are allowed to replicate, and on what terms. The KCC uses site links to build the intersite replication topology, so their properties directly control how AD data flows across your WAN.

The properties that matter. Cost expresses how expensive a path is; when multiple links could carry replication, the lower total cost wins. Replication interval sets how often intersite replication runs (15 minutes minimum, 180 by default). Schedule can restrict replication to off-hours windows. Transport is normally IP (RPC over IP); the legacy SMTP transport is essentially never used today.

The default link. Every domain starts with DEFAULTIPSITELINK (cost 100, interval 180, available 24x7). It works, but real designs create purpose-named links with tuned cost and schedule so replication follows the actual network paths and budgets.

Active Directory replicates the same data two different ways depending on whether the partners are in the same site or different sites. The distinction is entirely about cost: intra-site links are assumed fast and free, inter-site links are assumed slow and metered.

Intrasite replication. Within a site, replication is change-notification driven and near-instant. A DC that takes a change notifies its partners within about 15 seconds, and the data is sent uncompressed because bandwidth is plentiful. The KCC wires intra-site DCs into a ring with extra connections so no DC is more than three hops from any other.

Intersite replication. Between sites, replication follows the site link schedule (default every 180 minutes), and the payload is compressed (roughly 10:1) to conserve WAN bandwidth. It flows through bridgehead servers rather than every DC talking to every other DC. The trade is freshness for efficiency: branch DCs are slightly behind, but the link is not saturated.

The Knowledge Consistency Checker is the built-in process that designs the replication topology for you. Rather than an administrator hand-wiring which DC replicates with which, the KCC computes the connection objects automatically and keeps them current as the environment changes.

What it does. The KCC runs on every domain controller every 15 minutes. For intra-site partners it builds a ring (a full mesh when there are seven or fewer DCs) and guarantees no more than three hops between any two DCs. For inter-site replication it builds a least-cost spanning tree from the site links and routes traffic through bridgeheads, compressed.

The ISTG. One DC per site is elected the Inter-Site Topology Generator and owns the inter-site calculations for that site. If you add or remove DCs and do not want to wait for the next cycle, you can force a recompute.

The KCC's job is ongoing, not one-time. It continuously maintains the set of connection objects that define who replicates with whom, adapting the topology whenever the domain's shape changes.

Its core responsibilities. It runs on every DC every 15 minutes. It creates intra-site connection objects automatically, calculates the inter-site topology from the site links, and rebuilds the whole topology when DCs are added or removed. Throughout, it enforces the three-hop maximum inside a site so convergence stays fast.

When to intervene. The KCC is self-healing, so manual connection objects are rarely needed. The one common action is forcing an immediate rebuild after a topology change rather than waiting out the 15-minute cycle.

Because the KCC owns the topology, the practical skill is reading what it produced and confirming the resulting connections are healthy. Two commands cover the day-to-day inspection.

Listing connections. Each connection object names a source DC and the schedule on which the local DC pulls from it. Reviewing them confirms the KCC built the partnerships you expect, especially after adding a site or a DC.

Surfacing failures fast. On a large forest the full replication report is noisy, so filtering to errors only is how you find the one broken partnership without scrolling past dozens of healthy ones.

A bridgehead server is the domain controller a site uses to exchange replication with other sites. Instead of every DC in Site A talking to every DC in Site B, the bridgeheads on each side handle the inter-site traffic and then replicate locally to their own site's DCs. This keeps WAN connections few and compression effective.

How they are chosen. The KCC (specifically the ISTG) selects one bridgehead per site per directory partition, by default the DC with the lowest GUID. You can designate preferred bridgeheads manually, but if a preferred bridgehead fails the KCC will only fail over automatically when no preferred ones remain, so designating just one is a common self-inflicted outage.

Operational note. Let the KCC manage bridgeheads unless you have a specific reason (such as forcing replication onto a DC with the best WAN link). If you do set preferred bridgeheads, set more than one.

A site link bridge controls whether replication is transitive across site links. With bridging on, a chain of links behaves like one connected path; with it off, replication only flows directly along each individual link.

The default behavior. "Bridge all site links" is enabled by default, which means if Site A links to Site B and Site B links to Site C, then A can replicate to C through B even without a direct A-to-C link. For most networks (where the underlying IP network is fully routed) this is exactly what you want and requires no thought.

When to turn it off. Disable automatic bridging only in complex hub-and-spoke designs where the physical network does not allow every site to reach every other site. Then you create explicit site link bridges for just the paths that are actually routable, giving you precise control over which sites can replicate through which.

Replication problems almost always resolve into one of three layers, and checking them in order keeps you from chasing the wrong thing. Work from the network up to the data.

Layer 1, connectivity. Confirm the plumbing: time skew under five minutes (Kerberos breaks past it), DNS SRV records resolving, and the RPC ports open through any firewall. Most "replication" tickets are really one of these three.

Layer 2, replication. With connectivity good, ask AD itself. repadmin /replsummary gives a one-screen health roll-up across every DC, and repadmin /showrepl gives the per-partner detail with the last success and any error code.

Layer 3, convergence. Finally prove data actually flows: make a harmless change on one DC and confirm it appears on its partners within the expected window.

The repadmin tool is the workhorse for replication diagnostics. The two read-only commands below are where every investigation begins, before you change anything.

The summary view. repadmin /replsummary produces a compact table covering every DC, showing the largest replication delay and the count of failures for each partner. It answers "is anything wrong, and where" in a single screen, which is why it is the first command to run.

The detail view. Once the summary points at a suspect DC, repadmin /showrepl on that DC lists each inbound partner, the last successful replication time, and the specific error code for any failure. That error code is what you take into the fix.

After reading the state, these commands let you push replication and confirm the backlog is clearing. Use them once you understand the error, not as a reflex.

Forcing and inspecting. repadmin /syncall with the absolute, enterprise, and pushed flags forces a DC to replicate with all partners immediately. repadmin /queue shows the pending inbound replication backlog so you can watch it drain. Get-ADReplicationFailure returns the failures as objects you can sort and report on.

The usual culprits. When replication is genuinely broken, the cause is almost always DNS misconfiguration, RPC blocked by a firewall, time skew greater than five minutes, or lingering objects left by a DC that was offline past the tombstone lifetime.

SYSVOL is the shared folder, present on every domain controller, that holds Group Policy templates and logon scripts. Because policy must be identical everywhere, SYSVOL has to replicate to all DCs, and it does so with its own engine separate from normal AD replication.

FRS, the legacy engine. The File Replication Service shipped with Windows 2000 and 2003. It replicates whole files, resolves conflicts with a crude single-master model, and is fragile at scale. FRS is deprecated and unsupported on modern Windows Server; any domain still using it should migrate.

DFS-R, the modern engine. Distributed File System Replication has been the default for SYSVOL since Windows Server 2008. It uses Remote Differential Compression to send only the changed blocks of a file, handles conflicts gracefully, and scales to large, multi-site environments. New domains use it automatically.

If you inherit a domain, the first SYSVOL question is which engine it actually uses and, if a migration is underway, how far it has progressed. The dfsrmig tool answers both before you touch anything.

The global state. dfsrmig /getglobalstate reports the migration target the domain is moving toward: Start (0), Prepared (1), Redirected (2), or Eliminated (3, FRS fully removed). It tells you the intended destination of the migration.

The per-DC state. dfsrmig /getmigrationstate confirms whether every domain controller has actually reached that target. A migration is only complete when all DCs report the same state as the global target; a single lagging DC blocks finalization.

After a configuration change, DFS-R does not pick it up instantly; it polls Active Directory on a schedule. When you need the change applied now, force the poll and then confirm the share is healthy.

Forcing the poll. dfsrdiag pollad tells the DFS Replication service to read its configuration from AD immediately instead of waiting for the next automatic cycle. Run it on the DCs you just reconfigured so they converge without delay.

Confirming the share. The ultimate proof that SYSVOL replication is working is that the SYSVOL share exists and is accessible. Get-SmbShare -Name SYSVOL verifies the DC is actually advertising the share that clients and Group Policy depend on.

A Read-Only Domain Controller is a domain controller designed for locations you cannot fully secure, such as a branch office or a DMZ. It holds a copy of the directory but cannot be used to change it, which limits the damage if the box is stolen or compromised.

What makes it safe. Replication is one-way: an RODC pulls changes from writable DCs but never pushes, so a tampered RODC cannot poison the rest of AD. It caches no account passwords by default, and a filtered attribute set keeps designated sensitive attributes off the RODC entirely.

Selective password caching. To let branch users log on even when the WAN is down, you add their accounts to the RODC's Password Replication Policy allowed list, so only those passwords are cached locally. If the RODC is stolen, only that small, known set of credentials is at risk and can be reset.

The labs put this module into your hands. You will build a multi-site topology from nothing and then verify replication actually follows the design you created, the same workflow you would run on a real network.

In the GUI lab you create sites, add subnets and associate them, build site links with tuned cost and schedule, view the resulting topology, and force replication to watch it converge.

In the PowerShell lab you script the same build with New-ADReplicationSite, the subnet and site-link cmdlets, then drive and verify replication with repadmin. Doing it both ways cements which knob lives where.