How to Set Up Active Directory Backup and Recovery on Windows Server 2022

Understanding Active Directory Sites and Services

Active Directory Sites and Services is the component of AD DS responsible for managing the physical topology of your network — how domain controllers are grouped by network location, how replication traffic flows between them, and how clients are directed to the nearest domain controller for authentication. Proper site configuration is critical in multi-location environments: without it, a user in a remote office might authenticate against a domain controller across a slow WAN link instead of a local DC, and replication traffic might flow inefficiently between sites.

The management console is dssite.msc. Launch it from the Run dialog or from PowerShell:

Start-Process dssite.msc

PowerShell management of AD replication topology is handled through the ActiveDirectory module cmdlets prefixed with ADReplication:

Import-Module ActiveDirectory
Get-Command -Module ActiveDirectory -Noun ADReplication*

Core Concepts: Sites, Subnets, and Site Links

A Site in AD terminology represents a well-connected physical location — a group of IP subnets connected by high-speed, reliable links (typically a LAN segment). Domain controllers assigned to the same site replicate frequently and rapidly (within seconds to minutes). Sites also control how Kerberos tickets are issued and how clients locate DCs: a client always prefers a DC in its own site before trying a DC in a remote site.

A Subnet is an IP network range associated with a site. When a computer joins the domain or requests a DC via DNS, AD uses the client’s IP address to look up the matching subnet and determine which site the client belongs to. If no matching subnet exists, the client uses any available DC, which may be across the WAN.

A Site Link is an object that defines the path between two or more sites for replication purposes. It has a cost (lower cost = preferred path), a replication interval (how often replication is triggered in minutes), and a schedule (time windows when replication is allowed). Site links use one of two transports: IP (SMTP transport is deprecated and should not be used for AD DS replication).

Creating AD Sites with PowerShell

The default installation creates one site called Default-First-Site-Name. Rename it and create additional sites to match your network topology:

# Rename the default site to reflect the actual location
Get-ADReplicationSite -Filter {Name -eq "Default-First-Site-Name"} | 
  Set-ADReplicationSite -Description "New York Headquarters"
Rename-ADObject -Identity "CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=corp,DC=example,DC=com" `
  -NewName "NewYork"

# Create new sites for additional locations
New-ADReplicationSite -Name "London" -Description "London UK Office"
New-ADReplicationSite -Name "Singapore" -Description "Asia Pacific Hub"
New-ADReplicationSite -Name "Chicago" -Description "Midwest Regional Office"

# List all sites
Get-ADReplicationSite -Filter * | Select-Object Name, Description, WhenCreated

Creating and Associating Subnets

After creating sites, associate IP subnets with each site so that clients and DCs are automatically placed in the correct site:

# Create subnets and associate with sites
New-ADReplicationSubnet -Name "192.168.1.0/24" -Site "NewYork" -Description "NY HQ LAN"
New-ADReplicationSubnet -Name "192.168.2.0/24" -Site "London" -Description "London Office LAN"
New-ADReplicationSubnet -Name "10.10.1.0/24" -Site "Singapore" -Description "SG Office LAN"
New-ADReplicationSubnet -Name "10.20.1.0/24" -Site "Chicago" -Description "Chicago Office LAN"

# Verify subnet-to-site associations
Get-ADReplicationSubnet -Filter * | Select-Object Name, Site, Description

# Check which site a specific IP belongs to
nltest /dsgetsite

The subnet naming format must follow CIDR notation (network address/prefix length). Use the exact network address — for example, use 192.168.1.0/24 not 192.168.1.5/24. If a client’s IP does not match any subnet, AD logs event ID 5807 in the NETLOGON log indicating no site mapping was found.

Creating Site Links

Site links define the replication paths between sites. Each site link must include at least two sites. Create site links that mirror your actual WAN topology:

# Create a site link between New York and London
New-ADReplicationSiteLink `
  -Name "NewYork-London" `
  -SitesIncluded "NewYork","London" `
  -Cost 100 `
  -ReplicationFrequencyInMinutes 180 `
  -InterSiteTransportProtocol IP `
  -Description "MPLS link 10Mbps"

# Create a site link between New York and Singapore (higher cost = slower/less preferred)
New-ADReplicationSiteLink `
  -Name "NewYork-Singapore" `
  -SitesIncluded "NewYork","Singapore" `
  -Cost 250 `
  -ReplicationFrequencyInMinutes 360 `
  -InterSiteTransportProtocol IP `
  -Description "Internet VPN 2Mbps"

# Create a site link between New York and Chicago
New-ADReplicationSiteLink `
  -Name "NewYork-Chicago" `
  -SitesIncluded "NewYork","Chicago" `
  -Cost 50 `
  -ReplicationFrequencyInMinutes 60 `
  -InterSiteTransportProtocol IP `
  -Description "Dedicated fiber link"

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

Site Link Costs and Replication Intervals

The cost value on a site link influences which path the KCC (Knowledge Consistency Checker) selects when there are multiple routes between sites. Lower cost paths are preferred. Use cost values that roughly reflect the inverse of available bandwidth and reliability:

A typical cost scheme: 100 for a 1.5Mbps T1, 50 for a 10Mbps link, 25 for a 100Mbps link, and 10 for a 1Gbps link. The exact values do not matter as long as they are proportional — what matters is the relative comparison when the KCC calculates the spanning tree.

The ReplicationFrequencyInMinutes value controls how often AD checks for changes to replicate across this site link. The minimum is 15 minutes. For high-latency links, increase this value to reduce the number of replication connection attempts. Update an existing site link:

# Update cost and interval on an existing site link
Set-ADReplicationSiteLink -Identity "NewYork-London" -Cost 150 -ReplicationFrequencyInMinutes 240

# Enable site link bridging (disabled by default, allows indirect replication paths)
# This is controlled at the IP transport level
Set-ADReplicationSiteLink -Identity "NewYork-London" -OtherAttributes @{"options"=0}

By default, site link bridging is enabled (the “Bridge all site links” option in the IP transport properties in dssite.msc). This means if Site A links to Site B and Site B links to Site C, AD can automatically route replication from A to C through B. Disable bridging only if you need explicit control over replication paths.

Knowledge Consistency Checker (KCC)

The KCC is an automated process that runs on every domain controller and generates the replication topology — the set of replication connection objects that define which DC replicates from which other DC. The KCC runs every 15 minutes and adjusts the topology as DCs are added, removed, or become unavailable.

Within a site (intra-site replication), the KCC creates a bidirectional ring topology ensuring every DC can reach every other DC in at most two hops, and adds extra connections if there are more than 7 DCs in the site. Intra-site replication is triggered by change notification (within seconds of a change) and happens over uncompressed connections.

Between sites (inter-site replication), the KCC designates a bridgehead server in each site to handle inter-site replication. Only the bridgehead servers exchange replication data across site links, then replicate changes to all other DCs within their site. Inter-site replication is compressed and scheduled according to the site link’s interval and schedule.

Force the KCC to recalculate the topology immediately:

# Force KCC recalculation on a specific DC
repadmin /kcc DC01.corp.example.com

# Force KCC recalculation on all DCs in the domain
repadmin /kcc * /all

Bridgehead Servers

A bridgehead server is the DC in a site responsible for sending and receiving inter-site replication. By default, the KCC automatically selects bridgehead servers (ISTG — Inter-Site Topology Generator). You can specify preferred bridgehead servers to ensure that a DC with sufficient bandwidth and resources handles this role:

# Set a preferred bridgehead server for the IP transport
# This is done by setting the bridgeHeadTransportList attribute on the DC's NTDS settings object
$dc = Get-ADDomainController -Identity "DC01"
$transportDN = "CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=corp,DC=example,DC=com"
Set-ADObject -Identity $dc.NTDSSettingsObjectDN -Add @{bridgeHeadTransportList=$transportDN}

Use preferred bridgehead servers carefully — if the designated bridgehead server goes offline and no preferred server is available, inter-site replication stops entirely until the server is restored or the preference is removed. Automatic bridgehead selection by the KCC is more resilient for most environments.

Monitoring Inter-Site Replication

Repadmin is the primary tool for monitoring and troubleshooting AD replication across sites:

# Show replication status for all DCs
repadmin /showrepl * /csv > C:Temprepl_report.csv

# Show replication summary across all DCs
repadmin /replsummary

# Show replication connections for a specific DC
repadmin /showconn DC01.corp.example.com

# Check the current replication queue (pending operations)
repadmin /queue DC01.corp.example.com

# Force immediate replication of all naming contexts from all partners
repadmin /syncall DC01.corp.example.com /AdeP

# Show objects that have not replicated within the tombstone lifetime (lingering objects)
repadmin /removelingeringobjects DC02.corp.example.com DC01.corp.example.com DC=corp,DC=example,DC=com /advisory_mode

The /csv output from /showrepl is particularly useful — import it into Excel to filter and sort by site, error type, or timestamp. Look for any DC showing LastReplicationAttempt and LastReplicationSuccess with a significant gap, which indicates replication is failing silently.

PowerShell also provides replication monitoring:

# Get replication failures across all DCs
Get-ADReplicationFailure -Scope Forest

# Get replication queue for a specific DC
Get-ADReplicationQueueOperation -Server "DC01.corp.example.com"

# Get upstream replication partners for a DC
Get-ADReplicationPartnerMetadata -Target "DC01.corp.example.com" -Scope Server

# Show replication uptime statistics
Get-ADReplicationUpToDatenessVectorTable -Target "corp.example.com" -Scope Domain

Optimizing the AD Replication Topology

For large environments or when troubleshooting performance issues, consider these optimization strategies. First, ensure every site with a DC has at least two DCs for redundancy — a single-DC site creates a single point of failure for that location. Second, verify site assignments are correct by checking event ID 5807 in the NETLOGON event log on each DC, which indicates clients with no matching subnet.

Review the automatically generated connection objects in dssite.msc under each DC’s NTDS Settings node. Connection objects with automatically generated names (shown in angle brackets) are KCC-managed. Manually created connection objects take precedence and the KCC will not remove them — use them only when the automatic topology needs correction.

# List all replication connections in the domain
Get-ADReplicationConnection -Filter * | Select-Object Name, ReplicateFromDirectoryServer, ReplicateToDirectoryServer, AutoGenerated

# Remove a stale manually created connection object
Remove-ADReplicationConnection -Identity "CN=manually-created,CN=NTDS Settings,CN=DC02,CN=Servers,CN=London,CN=Sites,CN=Configuration,DC=corp,DC=example,DC=com"

Finally, schedule replication windows to avoid competing with business-critical WAN traffic. In dssite.msc, right-click a site link and choose Properties, then click the Change Schedule button to set which hours replication is permitted. For example, allowing replication only during off-peak hours (10pm to 6am) on a constrained WAN link reduces the impact of AD replication on user-facing applications during business hours.