How to Configure AD Sites and Services on Windows Server 2012 R2
Active Directory Sites and Services is the administrative tool used to manage the physical topology of your Active Directory infrastructure. Sites represent physical network segments or geographic locations connected by reliable, high-bandwidth links. The Sites and Services configuration drives replication scheduling, client site affinity (ensuring users authenticate against the nearest domain controller), and the publication of service records. Proper site configuration is critical for large or geographically distributed organisations to ensure efficient replication and fast authentication. This guide covers site creation, subnet association, site link configuration, and site link bridge settings on Windows Server 2012 R2.
Prerequisites
You must be a member of the Enterprise Admins or Domain Admins group to manage Sites and Services. The Active Directory Sites and Services MMC snap-in (dssite.msc) must be accessible. For PowerShell-based management, the ActiveDirectory module must be imported. Sites and Services applies across the entire forest, not just a single domain.
Import-Module ActiveDirectory
Understanding Sites and the KCC
A site in Active Directory represents a set of well-connected IP subnets. The Knowledge Consistency Checker (KCC) is an automatic process running on every domain controller that generates and maintains the replication topology. The KCC creates connection objects between DCs based on site link configuration, ensuring all DCs are reachable through a minimum of two hops. Within a site, replication is frequent (default 15 seconds after a change notification). Between sites, replication follows the site link schedule you configure.
Creating Sites
The default-first-site-name site is created automatically during domain setup. Rename it to reflect your first location, then create additional sites for each physical location:
# Rename the default site
Get-ADReplicationSite -Filter {Name -eq "Default-First-Site-Name"} |
Rename-ADObject -NewName "London-HQ"
# Create additional sites
New-ADReplicationSite -Name "New-York"
New-ADReplicationSite -Name "Singapore"
New-ADReplicationSite -Name "Frankfurt"
New-ADReplicationSite -Name "Sydney"
Creating and Associating Subnets
Subnets must be associated with sites so that when a domain controller or client queries Active Directory for its site, the correct site is returned based on the machine’s IP address. Without subnet-to-site mappings, all machines default to the first site, causing inefficient replication and authentication:
# Create subnets and associate them with sites
New-ADReplicationSubnet -Name "192.168.10.0/24" -Site "London-HQ" `
-Description "London HQ LAN - Floor 1-3"
New-ADReplicationSubnet -Name "192.168.20.0/24" -Site "London-HQ" `
-Description "London HQ LAN - Floor 4-6"
New-ADReplicationSubnet -Name "10.10.0.0/16" -Site "New-York" `
-Description "New York Office"
New-ADReplicationSubnet -Name "172.16.50.0/24" -Site "Singapore" `
-Description "Singapore Office"
New-ADReplicationSubnet -Name "10.20.0.0/24" -Site "Frankfurt" `
-Description "Frankfurt Office"
Verify subnet associations after creation:
Get-ADReplicationSubnet -Filter * |
Select-Object Name, Site, Description |
Sort-Object Site
Creating Site Links
Site links define the network paths between sites and carry the cost, replication frequency, and schedule information the KCC uses to build the replication topology. Lower cost site links are preferred. The default site link protocol is IP (RPC over IP); SMTP is available but not recommended and not supported for replication within the same domain:
# Create site links between locations
New-ADReplicationSiteLink -Name "London-HQ_to_New-York" `
-SitesIncluded @("London-HQ","New-York") `
-Cost 50 `
-ReplicationFrequencyInMinutes 180 `
-InterSiteTransportProtocol IP
New-ADReplicationSiteLink -Name "London-HQ_to_Singapore" `
-SitesIncluded @("London-HQ","Singapore") `
-Cost 100 `
-ReplicationFrequencyInMinutes 360 `
-InterSiteTransportProtocol IP
New-ADReplicationSiteLink -Name "London-HQ_to_Frankfurt" `
-SitesIncluded @("London-HQ","Frankfurt") `
-Cost 30 `
-ReplicationFrequencyInMinutes 120 `
-InterSiteTransportProtocol IP
Configuring Site Link Schedules
The replication schedule on a site link defines when replication is allowed to occur between sites. By default, replication is available 24 hours a day, 7 days a week. You can restrict replication to off-peak hours to reduce WAN bandwidth consumption during business hours:
# View current site link schedule
Get-ADReplicationSiteLink -Identity "London-HQ_to_Singapore" |
Select-Object Name, Cost, ReplicationFrequencyInMinutes
# Modify cost and frequency
Set-ADReplicationSiteLink -Identity "London-HQ_to_New-York" `
-Cost 75 `
-ReplicationFrequencyInMinutes 240
To configure a custom schedule (restrict to off-hours only), use the dssite.msc console. Right-click the site link, choose Properties, click Change Schedule, and deselect the business hours grid. This cannot be done via the standard PowerShell AD module and requires the GUI or ADSI manipulation.
Configuring Site Link Bridges
By default, all site links are bridged, meaning the KCC assumes all sites are transitively connected. If your network topology is not fully routed (e.g., hub-and-spoke), disable automatic site link bridging and create explicit site link bridges:
# Disable automatic site link bridging for IP transport
Set-ADReplicationSiteLink -Filter * | ForEach-Object {
# This is done at the transport level in dssite.msc
# Right-click IP under Inter-Site Transports, uncheck "Bridge all site links"
}
# Create an explicit site link bridge
New-ADReplicationSiteLinkBridge -Name "Hub-Spoke-Bridge" `
-SiteLinksIncluded @("London-HQ_to_New-York","London-HQ_to_Singapore") `
-InterSiteTransportProtocol IP
Moving Domain Controllers to Sites
When a new domain controller is promoted, it is placed in the site corresponding to its IP address and subnet mapping. If the subnet is not mapped, it lands in the first site. Move DCs to their correct sites after promotion if needed:
# Move a DC to the correct site
Move-ADDirectoryServer -Identity "DC-NY-01" -Site "New-York"
# Verify DC site assignment
Get-ADDomainController -Filter * |
Select-Object HostName, Site, IPv4Address |
Sort-Object Site
Designating Bridgehead Servers
A bridgehead server is the domain controller in a site that handles inter-site replication. The KCC automatically selects bridgehead servers (called Preferred Bridgehead Servers, PBS) but you can designate specific servers if needed. Avoid designating PBS in production as it can cause replication failures if that specific DC becomes unavailable — the KCC will not fail over to another DC:
# View automatically selected bridgehead servers
Get-ADReplicationConnection -Filter * |
Select-Object Name, AutoGenerated, ReplicateFromDirectoryServer |
Where-Object {$_.AutoGenerated -eq $false}
Verifying Site Configuration
# List all sites
Get-ADReplicationSite -Filter * |
Select-Object Name, Description
# List all subnets and their associated sites
Get-ADReplicationSubnet -Filter * |
Select-Object Name, Site, Description
# List all site links
Get-ADReplicationSiteLink -Filter * |
Select-Object Name, Cost, ReplicationFrequencyInMinutes, SitesIncluded
# Check replication connections generated by KCC
Get-ADReplicationConnection -Filter * |
Select-Object Name, ReplicateFromDirectoryServer, ReplicateToDirectoryServer
Troubleshooting Site Issues
# Check which site a computer belongs to
nltest /dsgetsite
# Check site of a remote machine
nltest /server:RemotePC01 /dsgetsite
# List DCs in a specific site
nltest /dclist:contoso.com | findstr "New-York"
Summary
Active Directory Sites and Services configuration on Windows Server 2012 R2 is essential for managing replication topology and ensuring users authenticate against the nearest domain controller. Proper site design begins with accurate subnet-to-site mappings, followed by site link creation with appropriate costs and replication frequencies that reflect your actual WAN topology. The KCC uses this information to automatically build an efficient replication topology. For non-fully-routed networks, consider disabling automatic site link bridging and creating explicit bridges. Regular verification of DC site assignments and replication connections helps catch configuration drift before it causes replication failures.