How to Configure Multi-Site Active Directory on Windows Server 2022

Understanding Active Directory Sites and Services

Active Directory Sites and Services is a Microsoft Management Console (MMC) snap-in and a core component of Active Directory that controls how directory replication occurs across a distributed network. An AD site is a logical representation of a physical network location — typically corresponding to a geographical location, a well-connected subnet, or a datacenter — where domain controllers are present and clients authenticate.

Sites serve several critical purposes in a multi-site AD deployment. First, they control replication topology: domain controllers within the same site replicate changes almost immediately (within 15 seconds by default), while domain controllers in different sites replicate on a schedule based on site link configuration. Second, they enable site-aware client behavior: when a Windows client needs to authenticate or locate services like SYSVOL, DNS, or DFS-N, it first queries for DCs and services in its own site before crossing a WAN link.

A properly designed AD site topology reduces WAN bandwidth consumption, improves authentication speed for remote users, and provides predictable replication behavior across your infrastructure.

Creating AD Sites with PowerShell

The ActiveDirectory PowerShell module provides cmdlets for managing all aspects of the site topology. The New-ADReplicationSite cmdlet creates a new site object in the Sites container in the Configuration partition of AD.

# Import the module (available by default on DCs)
Import-Module ActiveDirectory

# Create new sites for each physical location
New-ADReplicationSite -Name "London-Site" -Description "London Datacenter"
New-ADReplicationSite -Name "NewYork-Site" -Description "New York Datacenter"
New-ADReplicationSite -Name "Sydney-Site" -Description "Sydney Office"
New-ADReplicationSite -Name "Chicago-Site" -Description "Chicago Branch Office"

# List all sites
Get-ADReplicationSite -Filter * | Select-Object Name, Description, `
    Location, Created | Format-Table -AutoSize

# Rename a site
Set-ADReplicationSite -Identity "London-Site" -Description "London Primary DC Site"

# Get detailed information about a specific site
Get-ADReplicationSite -Identity "London-Site" -Properties *

By default, when AD DS is first installed, a default site called Default-First-Site-Name is created. All DCs are initially placed in this site. You should rename this site to match your first real location:

# Rename the default site
Rename-ADObject -Identity "CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=corp,DC=example,DC=com" `
    -NewName "HQ-Site"

# Verify the rename
Get-ADReplicationSite -Identity "HQ-Site"

Creating Site Links and Configuring Replication Schedule

Site links define the logical connections between sites over which replication can occur. They are not created automatically — you must explicitly create site links that reflect your actual WAN topology. A site link has three key attributes: cost (lower = preferred path), replication interval (in minutes), and a schedule (when replication is allowed).

# Create a site link between HQ and London
New-ADReplicationSiteLink `
    -Name "HQ-London-SiteLink" `
    -SitesIncluded @("HQ-Site", "London-Site") `
    -Cost 100 `
    -ReplicationFrequencyInMinutes 15 `
    -Description "Primary transatlantic link"

# Create a site link between HQ and New York (lower cost = more preferred)
New-ADReplicationSiteLink `
    -Name "HQ-NewYork-SiteLink" `
    -SitesIncluded @("HQ-Site", "NewYork-Site") `
    -Cost 50 `
    -ReplicationFrequencyInMinutes 15

# Create a site link between London and Sydney (higher cost = backup path)
New-ADReplicationSiteLink `
    -Name "London-Sydney-SiteLink" `
    -SitesIncluded @("London-Site", "Sydney-Site") `
    -Cost 200 `
    -ReplicationFrequencyInMinutes 60 `
    -Description "Asia-Pacific link - higher latency"

# List all site links
Get-ADReplicationSiteLink -Filter * | Select-Object Name, Cost, `
    ReplicationFrequencyInMinutes | Format-Table -AutoSize

# Modify an existing site link's cost
Set-ADReplicationSiteLink -Identity "HQ-London-SiteLink" -Cost 75

# Set a replication schedule (example: allow replication only during business hours)
$schedule = New-Object System.DirectoryServices.ActiveDirectory.ActiveDirectorySchedule
$schedule.SetDailySchedule("Monday","Eight","Zero","Friday","Seventeen","Zero")

# Note: Schedule is best configured via Sites and Services MMC console
# as the PowerShell API for schedules is limited

Site Link Bridges and Transitivity

By default, AD site links are transitive — the KCC treats all site links as connected, meaning a DC in Site A can reach a DC in Site C through a site link between A-B and B-C, even without a direct A-C link. This behavior is controlled by the Bridge all site links option in Sites and Services.

When you have a non-fully-routed network (not all sites can directly reach all other sites at the IP layer), you should disable site link bridging and create explicit site link bridge objects that tell AD which site links are physically connected:

# Disable automatic site link bridging (for non-fully-routed topologies)
$siteContainer = Get-ADObject -Identity "CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=corp,DC=example,DC=com" -Properties Options
# Set bit 2 to disable bridge all site links
Set-ADObject -Identity $siteContainer.DistinguishedName -Replace @{Options=2}

# Create a manual site link bridge connecting two site links
New-ADReplicationSiteLinkBridge `
    -Name "HQ-London-Sydney-Bridge" `
    -SiteLinksIncluded @("HQ-London-SiteLink", "London-Sydney-SiteLink") `
    -Description "Bridge for Asia-Pacific connectivity via London"

# List site link bridges
Get-ADReplicationSiteLinkBridge -Filter * | Format-Table Name, SiteLinksIncluded

Assigning Subnets to Sites

For site-aware client and DC location to work, you must associate IP subnets with sites using New-ADReplicationSubnet. When a client queries the DC Locator service, it uses its own IP address to find the corresponding subnet-to-site mapping and locate the nearest DC.

# Assign subnets to sites
New-ADReplicationSubnet -Name "10.10.0.0/16" -Site "HQ-Site" -Description "HQ corporate network"
New-ADReplicationSubnet -Name "10.20.0.0/16" -Site "London-Site" -Description "London datacenter"
New-ADReplicationSubnet -Name "10.30.0.0/16" -Site "NewYork-Site" -Description "New York datacenter"
New-ADReplicationSubnet -Name "172.16.0.0/20" -Site "Chicago-Site" -Description "Chicago branch"
New-ADReplicationSubnet -Name "192.168.50.0/24" -Site "Sydney-Site" -Description "Sydney office"

# List all subnets and their site assignments
Get-ADReplicationSubnet -Filter * | Select-Object Name, Site | Format-Table -AutoSize

# Check if a specific IP maps to a site
Get-ADReplicationSubnet -Filter { Name -like "10.20.*" }

# Update a subnet's site assignment
Set-ADReplicationSubnet -Identity "10.20.0.0/16" -Site "London-Site"

If a client’s IP address does not match any defined subnet, it will use any available DC in any site. This is a common cause of poor authentication performance in branch offices — the client authenticates against a DC across the WAN instead of a local DC.

Placing Domain Controllers in the Correct Sites

Domain controllers are assigned to sites based on the IP address of the DC matching a subnet-to-site mapping. If the DC’s IP matches a subnet assigned to a specific site, it is automatically placed there. You can verify and manually move DCs:

# Check what site each DC is in
Get-ADDomainController -Filter * | Select-Object Name, Site, IPv4Address | `
    Format-Table -AutoSize

# Move a DC to a different site
Move-ADDirectoryServer -Identity "LONDC01" -Site "London-Site"

# Verify the move
Get-ADDomainController -Identity "LONDC01" | Select-Object Name, Site

# Check DC registration in DNS (site-specific SRV records)
nslookup -type=srv _ldap._tcp.London-Site._sites.dc._msdcs.corp.example.com

The Knowledge Consistency Checker and Replication Topology

The Knowledge Consistency Checker (KCC) is an in-process task that runs on every DC every 15 minutes and automatically calculates the optimal replication topology. The KCC creates connection objects in AD that define which DCs replicate directly with each other. For intra-site replication, the KCC creates a ring topology. For inter-site replication, it uses the site links and their costs to determine the Inter-Site Topology Generator (ISTG) — one DC per site that is responsible for managing inter-site replication connections.

# Force the KCC to recalculate the replication topology immediately
repadmin /kcc

# Force KCC on all DCs
repadmin /kcc *

# View the replication connections on a specific DC
repadmin /showrepl LONDC01

# View all connection objects
Get-ADReplicationConnection -Filter * | Select-Object Name, `
    ReplicateFromDirectoryServer, AutoGenerated | Format-Table -AutoSize

# Find the ISTG for each site
Get-ADReplicationSite -Filter * -Properties InterSiteTopologyGenerator | `
    Select-Object Name, InterSiteTopologyGenerator

Forcing and Monitoring Replication

The repadmin command-line tool is the primary utility for managing and troubleshooting AD replication. Key commands for a multi-site deployment:

# Force immediate replication of all partitions from all partners
repadmin /syncall /AdeP

# Parameters:
# /A = all partitions (schema, configuration, domain, DNS zones)
# /d = identify DCs by distinguished name
# /e = replicate across site links (enterprise-wide)
# /P = push changes from this DC outward

# Replicate a specific partition from a specific DC
repadmin /replicate LONDC01 HQDC01 "DC=corp,DC=example,DC=com"

# View replication summary for all DCs
repadmin /replsummary

# Show replication status including failures
repadmin /showrepl * /csv > C:Temprepl-report.csv

# PowerShell equivalent - get replication status
Get-ADReplicationUpToDatenessVectorTable -Target "corp.example.com" -Scope Domain | `
    Select-Object Server, Partner, LastReplicationAttempt, LastReplicationResult, `
    LastReplicationSuccess | Format-Table -AutoSize

# Check for replication failures
Get-ADReplicationFailure -Target "corp.example.com" -Scope Domain | `
    Select-Object Server, FirstFailureTime, FailureCount, FailureType, `
    LastError | Format-Table -AutoSize

# Get the replication metadata for a specific object
repadmin /showobjmeta LONDC01 "CN=TestUser,OU=Users,DC=corp,DC=example,DC=com"

Site Link Cost, Interval, and Replication Schedule Optimization

Properly tuning site link costs and replication intervals is critical for multi-site performance. Cost should reflect relative bandwidth — a 1 Gbps link between sites should have a lower cost than a 100 Mbps link. A common scale:

# Cost recommendations based on link speed:
# 512 Kbps  = cost 1042
# 1 Mbps    = cost 500
# 10 Mbps   = cost 100
# 100 Mbps  = cost 50
# 1 Gbps    = cost 10
# 10 Gbps   = cost 5

Set-ADReplicationSiteLink -Identity "HQ-London-SiteLink" -Cost 50    # 100 Mbps MPLS
Set-ADReplicationSiteLink -Identity "HQ-NewYork-SiteLink" -Cost 10   # 1 Gbps direct fiber
Set-ADReplicationSiteLink -Identity "London-Sydney-SiteLink" -Cost 100 # 10 Mbps satellite

# Set replication frequency (minimum 15 minutes for inter-site)
Set-ADReplicationSiteLink -Identity "HQ-London-SiteLink" `
    -ReplicationFrequencyInMinutes 15    # Replicate every 15 minutes

Set-ADReplicationSiteLink -Identity "London-Sydney-SiteLink" `
    -ReplicationFrequencyInMinutes 60   # Less critical path, hourly is fine

Troubleshooting Inter-Site Replication Failures

When inter-site replication fails, the repadmin /replsummary output shows DCs with replication errors. Common error codes and their resolutions:

# Full diagnostic replication check
repadmin /replsum /bysrc /bydest /errorsonly

# Check for lingering objects (objects that exist on some DCs but were deleted on others)
repadmin /removelingeringobjects LONDC01 HQDC01 "DC=corp,DC=example,DC=com" /advisory_mode

# Common replication errors and checks:
# Error 1722 (RPC server unavailable) - check firewall, DNS, network connectivity
Test-NetConnection -ComputerName LONDC01 -Port 135  # RPC endpoint mapper
Test-NetConnection -ComputerName LONDC01 -Port 389  # LDAP
Test-NetConnection -ComputerName LONDC01 -Port 636  # LDAPS
Test-NetConnection -ComputerName LONDC01 -Port 49152 # RPC dynamic ports

# Error 8606 (insufficient attributes) - usually indicates lingering objects
# Error -2146893022 (target principal name incorrect) - check DC machine account and Kerberos

# Verify DNS SRV records are registered correctly for each site
dcdiag /test:dns /v /s:LONDC01

# Full DC diagnostic including replication
dcdiag /test:replications /s:LONDC01

# Check AD DS event logs for replication errors
Get-WinEvent -ComputerName LONDC01 -LogName "Directory Service" `
    -MaxEvents 20 | Where-Object { $_.LevelDisplayName -eq "Error" } | `
    Format-List TimeCreated, Message

# Verify domain controller is advertising itself in the correct site
nltest /dsgetdc:corp.example.com /site:London-Site /force

A well-configured multi-site AD topology with correct subnet assignments, appropriately costed site links, and monitored replication is the foundation of reliable authentication and directory services across a geographically distributed organization. Regular review of replication health using repadmin /replsummary should be part of standard operational procedures.