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

As organisations grow and establish offices in multiple geographic locations, a single-site Active Directory topology becomes a bottleneck. Clients authenticate against the nearest available domain controller, replication traffic floods WAN links, and Group Policy processing slows down for remote users. Multi-site Active Directory solves these problems by logically mapping physical network subnets to AD sites, directing clients to the closest domain controller automatically, and controlling replication frequency across each site link. Windows Server 2025 ships with the latest version of the AD Sites and Services snap-in and the full suite of Active Directory PowerShell cmdlets, making it straightforward to design, deploy, and maintain a multi-site topology entirely from the command line. This tutorial covers creating sites, mapping subnets, promoting additional domain controllers in a second site, configuring site links, and troubleshooting replication.

Prerequisites

An existing Active Directory domain (e.g., contoso.com) with at least one Windows Server 2025 DC.
A second network segment (e.g., 10.0.1.0/24) connected via WAN or VLAN to the primary site.
A Windows Server 2025 server at the second site ready to be promoted as a DC.
Domain Admin or Enterprise Admin credentials.
RSAT-AD-PowerShell feature installed on your management workstation or DC.
DNS resolution working between sites (conditional forwarders or integrated DNS).

Step 1: Create Active Directory Sites

By default, Active Directory creates a single site named Default-First-Site-Name. Rename this to a meaningful label and create your second site before mapping subnets to them. All commands run against any DC in the forest.

Import-Module ActiveDirectory

# Rename the default site to Site-A (e.g., your primary data centre)
$defaultSite = Get-ADReplicationSite -Identity "Default-First-Site-Name"
Set-ADReplicationSite -Identity $defaultSite -Description "Primary Data Centre - London"
Rename-ADObject -Identity $defaultSite.DistinguishedName -NewName "Site-A"

# Create the second site (e.g., a branch office in Edinburgh)
New-ADReplicationSite -Name "Site-B" -Description "Branch Office - Edinburgh"

# Verify both sites exist
Get-ADReplicationSite -Filter * | Select-Object Name, Description

Step 2: Create and Assign Subnets to Sites

Subnets are the mechanism by which AD determines which site a client belongs to. When a client machine starts, it queries DNS to find a domain controller in its site by matching its IP address against the registered subnets.

# Map the primary data centre subnet to Site-A
New-ADReplicationSubnet `
    -Name "192.168.1.0/24" `
    -Site "Site-A" `
    -Description "Primary DC LAN"

# Map the branch office subnet to Site-B
New-ADReplicationSubnet `
    -Name "10.0.1.0/24" `
    -Site "Site-B" `
    -Description "Edinburgh Branch LAN"

# Optionally add a management VLAN subnet also belonging to Site-A
New-ADReplicationSubnet `
    -Name "192.168.100.0/24" `
    -Site "Site-A" `
    -Description "Management VLAN"

# Confirm subnet-to-site mapping
Get-ADReplicationSubnet -Filter * | Select-Object Name, Site

Step 3: Install an Additional Domain Controller at Site-B

Promoting a new DC in Site-B ensures that users at the branch office authenticate locally and receive Group Policy without traversing the WAN. Specify the site name during promotion so AD registers the new DC in the correct site from the start.

# Run on the target server at Site-B (e.g., SRV-DC02 with IP 10.0.1.10)

# Install AD DS role
Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools

# Promote as additional DC — specify -SiteName to place it in Site-B
$securePassword = ConvertTo-SecureString "RestoreModePass2025!" -AsPlainText -Force

Install-ADDSDomainController `
    -DomainName "contoso.com" `
    -SiteName "Site-B" `
    -InstallDns:$true `
    -CreateDnsDelegation:$false `
    -ReplicationSourceDC "SRV-DC01.contoso.com" `
    -SafeModeAdministratorPassword $securePassword `
    -NoRebootOnCompletion:$false `
    -Force:$true

# After reboot — verify DC registration in the correct site
nltest /dsgetsite
# Expected: Site-B

Step 4: Configure the Site Link

Site links define how replication flows between sites. Each link has a cost (lower cost = preferred path) and a replication frequency. By default, AD creates a site link named DEFAULTIPSITELINK containing all sites. For fine-grained control, create a dedicated link between your two sites.

# Remove both sites from the default site link
$defaultLink = Get-ADReplicationSiteLink -Identity "DEFAULTIPSITELINK"
Set-ADReplicationSiteLink -Identity $defaultLink `
    -SitesIncluded @{Remove="Site-A","Site-B"}

# Create a dedicated site link between Site-A and Site-B
New-ADReplicationSiteLink `
    -Name "SiteLink-A-to-B" `
    -SitesIncluded "Site-A","Site-B" `
    -Cost 100 `
    -ReplicationFrequencyInMinutes 15 `
    -Description "Primary WAN link London to Edinburgh"

# For a 500 ms WAN link, increase cost; for 10 Gbps fibre, lower cost
# Replication frequency minimum is 15 minutes for inter-site replication

# Enable Change Notification across the site link (optional — replicates changes
# within seconds rather than waiting for the schedule, at the cost of WAN traffic)
$siteLink = Get-ADReplicationSiteLink -Identity "SiteLink-A-to-B"
$siteLink.Options = 1   # 1 = USE_NOTIFY (change notification)
Set-ADReplicationSiteLink -Instance $siteLink

# Verify site link configuration
Get-ADReplicationSiteLink -Identity "SiteLink-A-to-B" | `
    Select-Object Name, Cost, ReplicationFrequencyInMinutes, SitesIncluded, Options

Step 5: Configure Bridgehead Server Preference

By default, AD automatically selects bridgehead servers (the DCs responsible for inter-site replication). You can designate a preferred bridgehead to ensure the most capable server handles WAN replication traffic.

# Set SRV-DC01 as the preferred bridgehead for IP transport in Site-A
$dc01 = Get-ADDomainController -Identity "SRV-DC01"
$siteDN = (Get-ADReplicationSite -Identity "Site-A").DistinguishedName
$serverDN = "CN=SRV-DC01,CN=Servers,$siteDN"

# Add the IP transport NTDS Settings object to the preferred bridgehead list
Set-ADObject -Identity "CN=NTDS Settings,$serverDN" `
    -Add @{bridgeheadTransportList = "CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=contoso,DC=com"}

# Verify preferred bridgehead setting
Get-ADObject -Identity "CN=NTDS Settings,$serverDN" -Properties bridgeheadTransportList

Step 6: Verify SYSVOL Replication with DFS-R

Windows Server 2025 uses DFS-R (DFSR) to replicate SYSVOL between domain controllers. After adding the Site-B DC, verify that DFSR replication is healthy across sites.

# Check DFSR replication state on each DC
# Run on SRV-DC01
dfsrdiag ReplicationState /member:SRV-DC02 /rgname:"Domain System Volume"

# Use the built-in AD replication diagnostic tool
repadmin /replsummary

# Show replication status for all DCs
repadmin /showrepl SRV-DC02

# Check for replication errors
repadmin /showrepl * /errorsonly

# Force immediate replication from Site-A DC to Site-B DC
repadmin /syncall /AdeP SRV-DC02

# Monitor SYSVOL share availability on Site-B DC
Test-Path "\SRV-DC02SYSVOL"

Step 7: Configure Site-Specific DNS

Each DC runs an AD-integrated DNS zone. Clients in Site-B should receive DNS responses from SRV-DC02 to avoid WAN queries. Verify that site-specific SRV records are registered correctly.

# On SRV-DC02 — restart Netlogon to force re-registration of site-specific DNS SRV records
Restart-Service Netlogon

# Verify site-specific SRV records (clients use these to find the DC in their site)
Resolve-DnsName -Name "_ldap._tcp.Site-B._sites.contoso.com" -Type SRV -Server SRV-DC02
Resolve-DnsName -Name "_kerberos._tcp.Site-B._sites.contoso.com" -Type SRV -Server SRV-DC02

# Confirm a client in Site-B is using the local DC
# Run on a client machine in the 10.0.1.0/24 subnet:
nltest /dsgetsite          # Should return: Site-B
nltest /dsgetdc /site:Site-B /domain:contoso.com

Step 8: Troubleshoot AD Sites and Services

# List all replication connections between DCs
Get-ADReplicationConnection -Filter * | `
    Select-Object Name, ReplicateFromDirectoryServer, ReplicateToDirectoryServer

# Check if a client is in the right site
nltest /sc_verify:contoso.com      # Verify secure channel
nltest /query                      # Show DC the client is using

# Force a client to re-discover its site DC
nltest /dsflush

# View pending replication tasks in the queue
repadmin /queue SRV-DC02

# Check metadata for a specific DC
repadmin /showmeta "CN=SRV-DC02,OU=Domain Controllers,DC=contoso,DC=com"

# Diagnose replication failures in detail
dcdiag /test:replications /v
dcdiag /test:sysvolcheck /v

Conclusion

A properly designed multi-site Active Directory topology on Windows Server 2025 provides faster authentication, reduced WAN replication overhead, and resilient DNS resolution for users at every location. By carefully mapping subnets to sites, configuring site link costs and frequencies to reflect your actual network topology, and promoting domain controllers at each site, you ensure that clients always find the nearest DC while replication keeps all sites in sync. The PowerShell-driven approach documented here is fully scriptable and can be embedded in infrastructure-as-code pipelines, making it easy to add new sites as your organisation expands without manual intervention in the GUI. Regularly running repadmin /replsummary and dcdiag as scheduled tasks will alert you to replication failures before they escalate into authentication outages.

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