How to Set Up Active Directory Sites and Services on Windows Server 2025

How to Set Up Active Directory Sites and Services on Windows Server 2025

Active Directory Sites and Services is the component of AD DS that maps your logical directory to your physical network topology. Without a correct site configuration, domain controllers replicate over WAN links unnecessarily, clients authenticate against distant DCs instead of local ones, and distributed services like DFS and SYSVOL behave unpredictably. Windows Server 2025 inherits a mature site topology engine, and PowerShell’s ActiveDirectory module now exposes all of the site-related cmdlets needed to manage this infrastructure without leaving the command line. This tutorial covers creating sites and subnets, configuring site links with cost and schedule, managing bridgehead servers, verifying the replication topology, and understanding how site-aware services benefit from a well-designed site structure.

Prerequisites

• An Active Directory domain with at least one domain controller running Windows Server 2025
• Domain Admin or Enterprise Admin credentials
• The ActiveDirectory PowerShell module (Import-Module ActiveDirectory)
• Network subnet information for each physical location in your organization
• An understanding of the available bandwidth between sites (used to set site link costs)

# Verify the ActiveDirectory module is available
Import-Module ActiveDirectory

# Open the Sites and Services GUI
dssite.msc

Step 1: Rename the Default Site

Every AD installation creates a default site named Default-First-Site-Name. All domain controllers are placed in this site until you configure your topology. Before creating additional sites, rename this default site to represent your first physical location.

# Find the current default site
Get-ADReplicationSite -Filter * | Select-Object Name, DistinguishedName

# Rename the default site to reflect the first location
$DefaultSite = Get-ADReplicationSite -Identity "Default-First-Site-Name"
$DefaultSite | Rename-ADObject -NewName "HQ-London"

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

Step 2: Create Additional AD Sites

Each physical network location with its own local domain controller should have its own site. Sites tell AD which DCs are “local” to a subnet, ensuring that clients authenticate against the nearest DC and that replication traffic stays within the site unless it needs to cross a site link.

# Create additional sites for remote offices
New-ADReplicationSite -Name "Branch-New-York" `
    -Description "New York Branch Office" `
    -OtherAttributes @{ location = "New York, USA" }

New-ADReplicationSite -Name "Branch-Sydney" `
    -Description "Sydney Branch Office" `
    -OtherAttributes @{ location = "Sydney, Australia" }

New-ADReplicationSite -Name "Branch-Singapore" `
    -Description "Singapore Branch Office" `
    -OtherAttributes @{ location = "Singapore" }

# List all sites to confirm
Get-ADReplicationSite -Filter * | Select-Object Name, Description | Sort-Object Name

Step 3: Create Subnets and Associate Them with Sites

Subnets define which IP address ranges belong to each site. When a client or domain controller starts up, AD compares its IP address against the subnet list to determine site membership. Without subnet associations, clients fall back to the site of their domain controller, which may not be the correct local site.

# Create subnets for the London HQ
New-ADReplicationSubnet `
    -Name "192.168.10.0/24" `
    -Site "HQ-London" `
    -Location "London HQ - Floor 1"

New-ADReplicationSubnet `
    -Name "192.168.11.0/24" `
    -Site "HQ-London" `
    -Location "London HQ - Floor 2"

# Create subnets for the New York branch
New-ADReplicationSubnet `
    -Name "10.20.0.0/22" `
    -Site "Branch-New-York" `
    -Location "New York Branch Office"

# Create subnets for Sydney
New-ADReplicationSubnet `
    -Name "10.30.0.0/23" `
    -Site "Branch-Sydney" `
    -Location "Sydney Branch Office"

# Create subnets for Singapore
New-ADReplicationSubnet `
    -Name "10.40.0.0/23" `
    -Site "Branch-Singapore" `
    -Location "Singapore Branch Office"

# Verify all subnets and their site associations
Get-ADReplicationSubnet -Filter * | Select-Object Name, Site, Location | Sort-Object Name

Step 4: Create Site Links

Site links define the paths over which inter-site replication occurs. A site link must include at least two sites, a cost value (lower cost is preferred — analogous to a routing metric), and a replication frequency in minutes. The default inter-site transport is IP (RPC over IP); SMTP transport is available but rarely used because it cannot replicate the domain NC.

# Create a site link between London HQ and New York (high-bandwidth link)
New-ADReplicationSiteLink `
    -Name "SL-London-NewYork" `
    -SitesIncluded "HQ-London", "Branch-New-York" `
    -Cost 100 `
    -ReplicationFrequencyInMinutes 15 `
    -InterSiteTransportProtocol IP `
    -Description "50 Mbps MPLS link — London to New York"

# Create a site link between London HQ and Sydney (slower/more expensive WAN link)
New-ADReplicationSiteLink `
    -Name "SL-London-Sydney" `
    -SitesIncluded "HQ-London", "Branch-Sydney" `
    -Cost 250 `
    -ReplicationFrequencyInMinutes 60 `
    -InterSiteTransportProtocol IP `
    -Description "10 Mbps internet VPN — London to Sydney"

# Create a site link between London HQ and Singapore
New-ADReplicationSiteLink `
    -Name "SL-London-Singapore" `
    -SitesIncluded "HQ-London", "Branch-Singapore" `
    -Cost 200 `
    -ReplicationFrequencyInMinutes 30 `
    -InterSiteTransportProtocol IP `
    -Description "20 Mbps MPLS — London to Singapore"

# Verify all site links
Get-ADReplicationSiteLink -Filter * |
    Select-Object Name, Cost, ReplicationFrequencyInMinutes, SitesIncluded |
    Sort-Object Name

Step 5: Configure Site Link Bridges

By default, Bridge All Site Links is enabled, which means the KCC (Knowledge Consistency Checker) assumes all site links are transitive — i.e., if London can reach New York and London can reach Sydney, then New York and Sydney can transitively communicate. Disable this only in complex hub-and-spoke topologies where you need full control over replication paths.

# Check whether bridge all site links is enabled
$Transport = Get-ADReplicationSiteLinkBridge -Filter * -ErrorAction SilentlyContinue
if (-not $Transport) {
    Write-Host "No explicit site link bridges configured — Bridge All Site Links is in effect."
}

# To create an explicit site link bridge (used when Bridge All Site Links is disabled):
New-ADReplicationSiteLinkBridge `
    -Name "SLB-EuropeAsia" `
    -SiteLinksIncluded "SL-London-Singapore", "SL-London-Sydney" `
    -InterSiteTransportProtocol IP

# Check the IP transport options (to enable/disable Bridge All Site Links)
# This is done via ADSI Edit or the GUI: Sites > Inter-Site Transports > IP
# Properties > Bridge all site links checkbox

Step 6: Designate Preferred Bridgehead Servers

A bridgehead server is the DC responsible for sending and receiving replication traffic across a site link. By default, the KCC selects the bridgehead server automatically. You can designate a preferred bridgehead server to ensure replication uses a specific, well-connected DC — particularly important if some DCs in a site are on slower or firewalled network segments.

# Designate DC01 as a preferred bridgehead server for IP transport in HQ-London
$DC = Get-ADDomainController -Identity "DC01.corp.example.com"

# Set preferred bridgehead using the ADSI method (the ActiveDirectory module
# does not expose a direct cmdlet for this; use the DirectoryEntry approach)
$SiteObj = [ADSI]"LDAP://CN=HQ-London,CN=Sites,CN=Configuration,DC=corp,DC=example,DC=com"
$DCObj = [ADSI]"LDAP://$($DC.ComputerObjectDN)"

# The preferred bridgehead attribute is set on the DC's NTDS Settings object
$NTDSSettings = [ADSI]"LDAP://CN=NTDS Settings,$($DC.ComputerObjectDN)"
# Review the bridgeheadTransportList attribute via the GPMC or ADSI Edit GUI

# Verify the currently elected bridgehead servers via repadmin
repadmin /bridgeheads

Step 7: Verify Replication Topology

After configuring your site topology, verify that the KCC has generated a correct connection topology and that replication is succeeding between all sites. The repadmin tool is indispensable for this.

# Show inbound replication partners and last replication result for each DC
repadmin /showrepl

# Show a concise summary of replication status across all DCs
repadmin /replsummary

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

# Check the connection objects between DCs (auto-generated by KCC)
Get-ADReplicationConnection -Filter * |
    Select-Object Name, ReplicateFromDirectoryServer, ReplicateToDirectoryServer |
    Sort-Object Name

# Force replication of a specific naming context from a specific source
repadmin /replicate DC02.corp.example.com DC01.corp.example.com DC=corp,DC=example,DC=com

# Sync all DCs in the domain immediately
repadmin /syncall /AdeP

# Show replication queue (pending replication changes)
repadmin /showoutcalls

Step 8: Verify Site-Aware Services

Several key services use AD Sites for optimization. DFS Namespaces and Replication use sites to direct clients to the closest replica. SYSVOL (via DFSR) uses the site topology for replication scheduling. DNS SRV records published by domain controllers include site information so clients can discover the closest DC automatically.

# Verify that DC SRV records are published correctly for site-aware DNS
# Client machines query the _msdcs zone for the nearest DC
nslookup -type=SRV _ldap._tcp.HQ-London._sites.dc._msdcs.corp.example.com

# Check that SYSVOL replication is healthy across all sites
Get-DfsrMembership -GroupName "Domain System Volume" -ComputerName * |
    Select-Object ComputerName, FolderName, State, Enabled

# Verify DFS folder referrals respect site costs
dfsutil client referrals flush

# Check DFS replication backlog between two specific DCs
dfsrdiag.exe BackLog `
    /SendingMember:DC01.corp.example.com `
    /ReceivingMember:DC02.corp.example.com `
    /RGName:"Domain System Volume"

Step 9: Understanding the Inter-Site Topology Generator (ISTG)

The Inter-Site Topology Generator is a role automatically assigned to one DC per site. The ISTG is responsible for calculating the optimal inter-site replication connections by running the spanning-tree algorithm across the site link graph. The ISTG creates connection objects in AD between bridgehead servers in different sites.

# Find which DC is the ISTG for each site
$Sites = Get-ADReplicationSite -Filter *
foreach ($Site in $Sites) {
    $ISTG = Get-ADObject `
        -SearchBase $Site.DistinguishedName `
        -Filter { objectClass -eq 'nTDSSiteSettings' } `
        -Properties interSiteTopologyGenerator
    Write-Host "Site: $($Site.Name)  ISTG: $($ISTG.interSiteTopologyGenerator)"
}

# List all auto-generated replication connection objects (created by ISTG)
Get-ADReplicationConnection -Filter { AutoGenerated -eq $true } |
    Select-Object Name, ReplicateFromDirectoryServer, ReplicateToDirectoryServer

# List manually created connection objects (created by administrators)
Get-ADReplicationConnection -Filter { AutoGenerated -eq $false } |
    Select-Object Name, ReplicateFromDirectoryServer, ReplicateToDirectoryServer

Step 10: Move Domain Controllers into the Correct Sites

When you add a new domain controller, it is placed in the site that matches its IP subnet. If no matching subnet exists (or if the DC was added before subnets were configured), it may end up in the wrong site. You can move a DC between sites using PowerShell.

# Check which site each DC is currently in
Get-ADDomainController -Filter * |
    Select-Object Name, Site, IPv4Address | Sort-Object Site

# Move a domain controller to the correct site
Move-ADDirectoryServer `
    -Identity "DC-SYD01.corp.example.com" `
    -Site "Branch-Sydney"

# Verify the move
Get-ADDomainController -Identity "DC-SYD01.corp.example.com" |
    Select-Object Name, Site

# Force KCC to regenerate connection objects after the move
repadmin /kcc

Conclusion

A correctly designed Active Directory Sites and Services topology is essential for efficient replication, fast client authentication, and reliable distributed services across your entire organization. On Windows Server 2025, you have used PowerShell to rename and create sites, define subnets and associate them with sites, create site links with appropriate costs and replication schedules, verify the ISTG-generated topology, and confirm that site-aware services like DFS and SYSVOL are functioning correctly. As your organization grows and new office locations come online, follow the same process: create the site, add the subnet, create a site link to the hub site with an appropriate cost, deploy a local DC, and verify replication with repadmin /replsummary. Keeping this topology accurate will save hours of troubleshooting replication and authentication issues over the lifetime of the infrastructure.