1.5 Active Directory Sites, Subnets & Site Link Topology

Active Directory Sites, Subnets & Site Link Topology

In hybrid and enterprise multi-site environments, Active Directory Domain Services must balance rapid directory consistency against wide-area network (WAN) bandwidth consumption. The site topology is the map that makes that balance possible: it tells domain controllers which replication partners are cheap to reach, and it tells clients which domain controller is physically nearest. Get the site and subnet design wrong and every symptom that follows — slow logons, authentication crossing an ExpressRoute circuit, Azure IaaS virtual machines authenticating against an on-premises domain controller — looks like a network problem when it is really a directory-configuration problem.

---

1. Active Directory Sites, Subnets & Site Links Architecture

An Active Directory Site represents a well-connected physical location defined by high-bandwidth, low-latency IP subnets (typically a local datacenter or campus LAN).

+-----------------------------------------------------------------------------+
|                     AD DS SITES AND SUBNETS ARCHITECTURE                    |
|                                                                             |
|   [SITE: HQ-Dallas]                           [SITE: Branch-Chicago]        |
|   Subnets: 10.10.0.0/16, 10.20.0.0/16         Subnets: 192.168.1.0/24       |
|   +--------------------------+                +--------------------------+  |
|   | DC-DAL-01 | DC-DAL-02    |                | BR-CHI-01 (RODC)         |  |
|   +--------------------------+                +--------------------------+  |
|                 \                                  /                        |
|                  +========= [SITE LINK: DAL-CHI] ==+                        |
|                             Cost: 50                                        |
|                             Replication Frequency: 30 mins                  |
|                             Schedule: 24x7 Available                        |
+-----------------------------------------------------------------------------+

Core Components:

1. IP Subnets: IP subnet objects (e.g., 10.10.1.0/24, fe80::/64) are created in Active Directory Sites and Services and explicitly associated with a Site. When a domain-joined client boots, the Netlogon service matches the client's current IP address against the subnet objects to determine its local site, querying DNS for site-specific SRV records (e.g., _ldap._tcp.HQ-Dallas._sites.dc._msdcs.corp.contoso.com).
2. Site Links: Site links connect two or more sites, modeling the WAN connectivity between them. Site links use the IP transport (RPC over IP) for all intra-forest replication. (The legacy SMTP transport is restricted to asynchronous inter-site replication across non-contiguous forests without RPC connectivity and cannot replicate the Domain directory partition).
3. Site Link Cost: A relative integer cost metric (range: 1 to 32767, default: 100). Active Directory uses Dijkstra's shortest-path algorithm to calculate the lowest cumulative cost path between sites.
4. Replication Frequency & Schedule:
   • Frequency: Defines how often inter-site replication is attempted during allowable hours (default: 180 minutes, minimum configurable: 15 minutes).
   • Schedule: A 7-day, 24-hour bitmap grid determining the specific hours when replication across the WAN is permitted.

---

2. Site Links: Cost, Schedule and Replication Interval

A site link is the object that says two or more sites can replicate with each other and how expensive that path is. Every new forest ships with one site link named DEFAULTIPSITELINK in the IP (RPC over IP) transport container, and every site you create is placed into it unless you move it.

Cost is relative, not a unit of bandwidth. A common design assigns cost inversely to link speed — a 1 Gbps metro fibre link might be cost 10, a 100 Mbps MPLS circuit cost 50, and a satellite branch cost 500 — so the KCC naturally routes through the fast paths. Two competing routes with identical cost cause the KCC to choose by the site link's globally unique identifier (GUID), which is effectively arbitrary; if you care which path wins, make the costs different.

# Create a site, a subnet mapped to it, and a costed site link
New-ADReplicationSite -Name 'AzureEastUS'
New-ADReplicationSubnet -Name '10.20.0.0/16' -Site 'AzureEastUS' -Location 'Azure East US VNet'

New-ADReplicationSiteLink -Name 'HQ-to-AzureEastUS' `
    -SitesIncluded 'HQ-Seattle','AzureEastUS' `
    -Cost 30 -ReplicationFrequencyInMinutes 15 -InterSiteTransportProtocol IP

# Tighten an existing link and confirm the values that are actually stored
Set-ADReplicationSiteLink -Identity 'DEFAULTIPSITELINK' -Cost 100 -ReplicationFrequencyInMinutes 60
Get-ADReplicationSiteLink -Filter * -Properties Cost,ReplicationFrequencyInMinutes,SitesIncluded |
    Format-Table Name,Cost,ReplicationFrequencyInMinutes

Site Link Bridging and Transitivity

By default the forest has Bridge all site links enabled on the IP transport, which makes every site link transitive: if HQ links to Branch-A and HQ links to Branch-B, the KCC treats Branch-A and Branch-B as reachable through HQ even though no link joins them directly. That is the correct setting for a fully routed IP network. You disable bridging — and then build explicit site link bridge objects — only when the physical network is not fully routed, for example when two branch networks can each reach the hub but cannot reach each other.

3. Bridgehead Servers and Automatic Site Coverage

Inter-site replication never happens between arbitrary pairs of domain controllers. In each site, the Intersite Topology Generator nominates one bridgehead server per directory partition per transport, and all inter-site traffic funnels through it. You can nominate a preferred bridgehead server manually in Active Directory Sites and Services, but doing so is a trap the exam likes: if every preferred bridgehead you designated is offline, Active Directory does not fall back to an unlisted domain controller, and inter-site replication for that partition stops entirely.

Automatic site coverage solves the opposite problem — a site with subnets and users but no domain controller. Domain controllers in the next-lowest-cost site register site-specific SRV records in DNS on behalf of the empty site, so clients there still find a sensible domain controller instead of a random one. Where a site has no local domain controller and slow WAN links, enable Universal Group Membership Caching (UGMC) on the site: a domain controller caches a user's universal group memberships at first logon and refreshes them every eight hours, which allows logon without contacting a global catalog across the WAN.

4. Subnet-to-Site Mapping, DC Locator and Hybrid Design

The DC Locator process is what turns the site topology into real client behaviour. A client sends its IP address to a domain controller during the initial DsGetDcName call; the domain controller compares that address against the subnet objects in the directory, returns the name of the site the client belongs to, and the client then queries DNS for site-specific SRV records under _tcp.<SiteName>._sites.dc._msdcs.<domain>. Any subnet that is not defined in Active Directory produces a client with no site affinity, which then authenticates against whichever domain controller answers first — frequently one across the WAN.

:: Which site does this machine believe it is in, and which DC did it choose?
nltest /dsgetsite
nltest /dsgetdc:corp.contoso.com /force

:: Log unmapped subnets: NETLOGON writes entries to %SystemRoot%\debug\netlogon.log

[!IMPORTANT] Hybrid rule: create one Active Directory site per Azure region that hosts domain controllers, and register every Azure virtual network address space as a subnet object mapped to that site. Without it, Azure IaaS virtual machines have no site affinity and will authenticate over the VPN or ExpressRoute circuit back to on-premises domain controllers — the single most common cause of "slow logon in Azure" tickets.

Moving a domain controller between sites is a directory operation, not a reinstall:

Move-ADDirectoryServer -Identity 'DC-AZ-01' -Site 'AzureEastUS'
Get-ADDomainController -Filter * | Format-Table Name,Site,IPv4Address,IsGlobalCatalog