M15: AD Sites & Replication

Active Directory Sites and Replication optimizes network traffic by controlling how and when directory data is replicated between domain controllers across different physical locations.

What You'll Learn

  • Understanding AD sites and subnets
  • Configuring site links and costs
  • Intrasite vs intersite replication
  • Knowledge Consistency Checker (KCC)
  • Troubleshooting replication issues

Prerequisites

  • Active Directory fundamentals (M02)
  • DNS concepts (M08)
  • Understanding of network topology
  • Windows Server administration
Enterprise Impact: Proper site configuration ensures users authenticate to the nearest domain controller, reducing WAN traffic and improving logon performance across branch offices.
Sites group DCs by physical locationUS-East siteDC01DC0210.0.0.0/16EU siteDC0310.1.0.0/16APAC siteDC0410.2.0.0/16WANWANWhy sites matter:Clients authenticate against the closest DC (same site)Replication compresses + schedules over slow WAN linksApps like Exchange use site to pick closest server

What Are AD Sites?

An AD site represents a set of well-connected IP subnets, typically a physical location with high-speed network connectivity.

Site Purposes

  • Control replication traffic flow
  • Direct clients to local DCs
  • Optimize DFS namespace referrals
  • Control service location (printers, apps)

Site Components

  • Sites: Logical containers for subnets
  • Subnets: IP ranges mapped to sites
  • Site Links: Connections between sites
  • Servers: DCs assigned to sites

Multi-Site Architecture

HQ Site
10.0.0.0/16
Branch Site
10.1.0.0/16
DR Site
10.2.0.0/16
Topology object describing physical layoutAD Sites

Subnets and Site Association

Subnets define IP address ranges and must be associated with sites for proper client-DC mapping.

IP subnet → Site assignmentSubnet Mapping

Why Subnet Mapping Matters

Why Subnet Mapping Matters

  • Clients use their IP to find the nearest DC
  • Unmapped subnets cause random DC selection
  • Performance and bandwidth suffer without proper mapping
  • GPO processing may use wrong site-linked policies

Creating a subnet and assigning it to a site tells AD which physical location that IP range belongs to, so clients on that network authenticate locally.

# Associate the 10.1.0.0/16 IP range with the Branch-Office site PS C:\> New-ADReplicationSubnet -Name "10.1.0.0/16" -Site "Branch-Office"
# Expected output: Name Site Location ---- ---- -------- 10.1.0.0/16 Branch-Office

Listing all subnets confirms every IP range in your organization has a site assignment, preventing random DC selection.

# List all subnets and their site assignments PS C:\> Get-ADReplicationSubnet -Filter * | Select Name, Site
# Expected output: Name Site ---- ---- 10.0.0.0/16 CN=HQ-Site,CN=Sites,CN=Configuration,DC=hexworth,DC=local 10.1.0.0/16 CN=Branch-Office,CN=Sites,CN=Configuration,DC=hexworth,DC=local 10.2.0.0/16 CN=DR-Site,CN=Sites,CN=Configuration,DC=hexworth,DC=local

If a subnet moves to a different physical location, reassign it to the correct site without deleting and recreating it.

# Reassign an existing subnet to a different site PS C:\> Set-ADReplicationSubnet -Identity "10.1.0.0/16" -Site "New-Site"
Best Practice: Document all IP subnets in your organization and ensure each is assigned to the correct site. Undocumented subnets lead to suboptimal authentication paths.
IP subnet → Site assignmentSubnet Mapping

Site Links

Site links define the replication paths between sites and control how AD data flows across WAN connections.

Site Link Properties

  • Cost: Lower = preferred path
  • Replication Interval: How often (min 15 min)
  • Schedule: When replication occurs
  • Transport: RPC (IP) or SMTP

Default Site Link

  • DEFAULTIPSITELINK created automatically
  • Cost: 100
  • Interval: 180 minutes
  • Schedule: 24x7

Creating a dedicated site link with a lower cost and shorter interval ensures replication happens faster over the high-bandwidth HQ-to-branch connection.

# Create a site link between HQ and Branch with fast replication PS C:\> New-ADReplicationSiteLink -Name "HQ-Branch" -SitesIncluded HQ-Site,Branch-Site -Cost 50 -ReplicationFrequencyInMinutes 15
# Expected output: Name Cost ReplicationFrequencyInMinutes SitesIncluded ---- ---- ---------------------------- ------------- HQ-Branch 50 15 {HQ-Site, Branch-Site}

Lowering the cost of a site link makes it the preferred replication path when multiple routes exist between sites.

# Lower the cost to make this the preferred replication path PS C:\> Set-ADReplicationSiteLink -Identity "HQ-Branch" -Cost 25
Cost Calculation: Use inverse of bandwidth. A 10Mbps link might have cost 100, while a 100Mbps link has cost 10. Lower cost = faster perceived connection.
Without map, clients hit random DCWhy subnet maps matter

Intrasite vs Intersite Replication

AD uses different replication strategies depending on whether DCs are in the same or different sites.

Intrasite (Within Site)

  • Change notification-based
  • Near-instant replication
  • Uncompressed data transfer
  • Ring topology by default
  • Assumes high bandwidth/low latency

Intersite (Between Sites)

  • Schedule-based (default 180 min)
  • Compressed data (60-80% reduction)
  • Bridgehead servers handle transfers
  • Designed for WAN conservation
  • Can use notification for urgent changes

Replication Timing

Change Made
DC1 (HQ)
15 sec
Intrasite
DC2 (HQ)
15-180 min
Intersite
DC3 (Branch)
Site Links = configured replication pathsUSDC01, DC02EUDC03APACDC04Link cost: 100Link cost: 200Optional US→APAC link, cost: 400Costlower = preferred pathSchedulewhen to replicate (e.g., off-hours only)

Knowledge Consistency Checker (KCC)

The KCC is an automatic process that creates and maintains the replication topology.

Replication: fast inside, scheduled betweenIntrasitewithin one siteDC01DC02RPCnotify-based~15 secondsno compressioncost-freeFor: same LANIntersiteacross sitesDC02DC03IP or SMTPscheduled~180 minutes defaultcompressed (≥50KB)cost-awareFor: WAN, slow links

KCC Functions

Replication: fast inside, scheduled betweenIntrasitewithin one siteDC01DC02RPCnotify-based~15 secondsno compressioncost-freeFor: same LANIntersiteacross sitesDC02DC03IP or SMTPscheduled~180 minutes defaultcompressed (≥50KB)cost-awareFor: WAN, slow links

KCC Functions

KCC Functions

  • Runs on every DC every 15 minutes
  • Creates intrasite connection objects automatically
  • Calculates intersite topology from site links
  • Rebuilds topology when DCs are added/removed
  • Ensures no more than 3 hops between any DCs in a site

When you add or remove DCs, force the KCC to rebuild the replication topology immediately rather than waiting for its 15-minute cycle.

# Trigger the KCC to recalculate the replication topology now PS C:\> repadmin /kcc
# Expected output: Consistency check on DC01.hexworth.local successful.
Replication: fast inside, scheduled betweenIntrasitewithin one siteDC01DC02RPCnotify-based~15 secondsno compressioncost-freeFor: same LANIntersiteacross sitesDC02DC03IP or SMTPscheduled~180 minutes defaultcompressed (≥50KB)cost-awareFor: WAN, slow links

KCC Functions (cont.)

Connection objects represent the replication partnerships that KCC has automatically created between domain controllers.

# List all automatic replication connection objects PS C:\> Get-ADReplicationConnection -Filter *
# Expected output: Name ReplicateFromDirectoryServer AutoGenerated ---- ---------------------------- ------------- {GUID} CN=DC02,CN=Servers,CN=HQ-Site... True {GUID} CN=DC03,CN=Servers,CN=Branch-Site... True

Filtering for errors-only across all DCs quickly reveals any replication partnerships that are failing.

# Show only replication errors across all domain controllers PS C:\> repadmin /showrepl * /errorsonly
# Expected output (healthy environment): Replication Summary Start Time: 2025-01-15 09:30:00 Beginning data collection for replication summary, this may take awhile: ........ Source DSA largest delta fails/total %% error DC01 00m:15s 0 / 5 0 DC02 00m:15s 0 / 5 0
Don't Override KCC: While you can manually create connection objects, let KCC manage topology when possible. Manual connections are not automatically adjusted if servers fail.
Replication: fast inside, scheduled betweenIntrasitewithin one siteDC01DC02RPCnotify-based~15 secondsno compressioncost-freeFor: same LANIntersiteacross sitesDC02DC03IP or SMTPscheduled~180 minutes defaultcompressed (≥50KB)cost-awareFor: WAN, slow links

Bridgehead Servers

Bridgehead servers are the designated replication partners for intersite traffic.

How Bridgehead Selection Works

  • KCC automatically selects a bridgehead per site per partition
  • Selection based on DC GUID (lowest wins by default)
  • Preferred bridgeheads can be manually configured
  • If bridgehead fails, KCC selects new one automatically

Querying the bridgeheadServerListBL attribute shows which DCs are currently acting as bridgehead servers for intersite replication.

# Query which DCs are designated as bridgehead servers per site PS C:\> Get-ADReplicationSite -Filter * | Get-ADObject -Properties bridgeheadServerListBL
# Expected output: Name ObjectClass bridgeheadServerListBL ---- ----------- ---------------------- HQ-Site site {CN=DC01,CN=Servers,CN=HQ-Site...} Branch-Site site {CN=DC03,CN=Servers,CN=Branch-Site...}

Manually designating a preferred bridgehead ensures your most powerful DC handles the intersite replication load instead of leaving it to GUID-based selection.

# Designate DC1 as the preferred bridgehead server for HQ-Site PS C:\> Set-ADObject -Identity "CN=DC1,CN=Servers,CN=HQ-Site,CN=Sites,CN=Configuration,DC=hexworth,DC=local" -Add @{bridgeheadTransportList="CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=hexworth,DC=local"}
High Availability Tip: If you have multiple DCs in a site, consider setting two preferred bridgeheads for redundancy. If one fails, the other is already designated.
Knowledge Consistency Checker auto-builds topologyKCC

Site Link Bridges

Site link bridges control whether transitive replication is allowed across site links.

Understanding Transitivity

  • By default, all site links are bridged (transitive)
  • Site A connects to B, B to C means A can replicate to C
  • Disable bridging when you need explicit control
  • Create manual bridges for specific paths

Site Link Bridge Example

Site A
NYC
Link 1
Site B
Chicago
Link 2
Site C
LA

With bridging: NYC can replicate directly to LA via Chicago

When to Disable Bridging: Only disable automatic bridging in complex hub-and-spoke networks where you need explicit control over replication paths.
Runs every 15 min, manages connection objectsKCC Functions

Replication Troubleshooting

Use these tools and techniques to diagnose and resolve replication problems.

Bridgehead = the one DC that handles intersite repUS siteDC01bridgeheadDC02DC02 ↔ DC01 intrasiteDC01 → intersite onlyintersiteEU siteDC03bridgeheadDC04Only the bridgehead talks across the WAN. Others get updates intrasite.ISTG (Inter-Site Topology Generator) picks bridgehead per site

Key Diagnostic Commands

Bridgehead = the one DC that handles intersite repUS siteDC01bridgeheadDC02DC02 ↔ DC01 intrasiteDC01 → intersite onlyintersiteEU siteDC03bridgeheadDC04Only the bridgehead talks across the WAN. Others get updates intrasite.ISTG (Inter-Site Topology Generator) picks bridgehead per site

Key Diagnostic Commands

Key Diagnostic Commands

The replication summary gives a quick health check across every DC, showing the largest replication delay and failure count for each partner.

# Get a high-level replication health summary for all DCs PS C:\> repadmin /replsummary
# Expected output: Replication Summary Start Time: 2025-01-15 09:30:00 Source DSA largest delta fails/total %% error -------------- ------------- ----------- -- ----- DC01 00m:15s 0 / 5 0 DC02 01m:30s 0 / 5 0 DC03 15m:00s 0 / 3 0

For a specific DC, showrepl displays each replication partner, the last successful sync time, and any errors.

# Show detailed replication status for a specific domain controller PS C:\> repadmin /showrepl DC1
# Expected output: DC01.hexworth.local DSA Options: IS_GC Site Options: (none) Inbound Neighbors: DC=hexworth,DC=local DC02 via RPC Last attempt @ 2025-01-15 09:28:00 was successful. Last success @ 2025-01-15 09:28:00.
Bridgehead = the one DC that handles intersite repUS siteDC01bridgeheadDC02DC02 ↔ DC01 intrasiteDC01 → intersite onlyintersiteEU siteDC03bridgeheadDC04Only the bridgehead talks across the WAN. Others get updates intrasite.ISTG (Inter-Site Topology Generator) picks bridgehead per site

Key Diagnostic Commands (cont.)

When you need changes propagated immediately, syncall forces replication across all DCs including transitive partners.

# Force immediate replication from DC1 to all partners (push mode) PS C:\> repadmin /syncall DC1 /AeD

Checking the replication queue reveals whether changes are backed up waiting to be sent or received.

# Check if any replication operations are queued and waiting PS C:\> repadmin /queue
# Expected output: Current queue contains 0 items.

The PowerShell cmdlet provides structured failure data that can be filtered, sorted, and exported for reporting.

# Query all replication failures across the domain using PowerShell PS C:\> Get-ADReplicationFailure -Target hexworth.local -Scope Domain
# Expected output (healthy environment): Server FirstFailureTime FailureCount LastError Partner ------ ---------------- ------------ --------- ------- (no output = no failures detected)

Common Issues

  • DNS resolution: DCs can't find replication partners
  • Firewall: RPC ports blocked (135, 49152-65535)
  • Time sync: >5 min skew breaks Kerberos
  • Lingering objects: Old objects on isolated DCs
Bridgehead = the one DC that handles intersite repUS siteDC01bridgeheadDC02DC02 ↔ DC01 intrasiteDC01 → intersite onlyintersiteEU siteDC03bridgeheadDC04Only the bridgehead talks across the WAN. Others get updates intrasite.ISTG (Inter-Site Topology Generator) picks bridgehead per site

SYSVOL Replication

SYSVOL contains Group Policy templates and scripts that must be synchronized across all DCs.

FRS (Legacy)

  • File Replication Service
  • Used in Windows 2000/2003
  • Single-master conflict resolution
  • Deprecated - should migrate away

DFS-R (Modern)

  • Distributed File System Replication
  • Default since Windows Server 2008
  • RDC for bandwidth efficiency
  • Better conflict handling
ISTG picks lowest GUID DC by defaultBridgehead Selection

SYSVOL Replication, Configuration

Before migrating from FRS, check whether your domain has already completed the migration to DFS-R by querying the global state.

# Check the current SYSVOL replication migration state PS C:\> dfsrmig /getglobalstate
# Expected output: Current DFSR global state: 'Eliminated' Succeeded.
# Verify all DCs have reached the target migration state PS C:\> dfsrmig /getmigrationstate
# Expected output: All Domain Controllers have migrated successfully to the Global state ('Eliminated'). Migration has reached a consistent state on all Domain Controllers. Succeeded.
ISTG picks lowest GUID DC by defaultBridgehead Selection

SYSVOL Replication, Configuration (cont.)

Forcing AD polling ensures the DFS-R service picks up any recent configuration changes without waiting for the next automatic cycle.

# Force DFS-R to poll Active Directory for configuration changes PS C:\> dfsrdiag pollad
# Expected output: Command completed successfully. Operation Succeeded - PollAD for member DC01.hexworth.local.

Verifying the SYSVOL share is accessible confirms that Group Policy objects can be served to clients from this DC.

# Confirm the SYSVOL share exists and is accessible PS C:\> Get-SmbShare -Name SYSVOL
# Expected output: Name ScopeName Path Description ---- --------- ---- ----------- SYSVOL * C:\Windows\SYSVOL\sysvol Logon server share
ISTG picks lowest GUID DC by defaultBridgehead Selection

Read-Only Domain Controllers

RODCs provide AD authentication in branch offices with limited physical security.

RODC Characteristics

  • One-way replication (receive only)
  • No passwords cached by default
  • Filtered attribute set for sensitive data
  • Cannot make changes to AD
  • Ideal for branch offices, DMZs

Deploying an RODC to a branch site gives local users fast authentication without storing a writable copy of the AD database at a less-secure location.

# Promote a server as a Read-Only Domain Controller in the branch site PS C:\> Install-ADDSDomainController -DomainName "hexworth.local" -ReadOnlyReplica:$true -SiteName "Branch-Site"
# Expected output: Message : The operation completed successfully. The server was successfully configured as a domain controller. Status : Success RebootRequired : True

The Password Replication Policy controls which user passwords are cached on the RODC. Only cache passwords for users who regularly log on at that branch.

# Allow the Branch-Users group to have passwords cached on the RODC PS C:\> Add-ADDomainControllerPasswordReplicationPolicy -Identity "RODC1" -AllowedList "Branch-Users"
# Expected output: AllowedList DeniedList ----------- ---------- {Branch-Users} {Denied RODC Password Replication Group}
Security Note: Configure the Password Replication Policy (PRP) to cache only passwords for users who regularly log on at that branch office.
Transitive replication path inferenceSite Link Bridges

Lab Preview: AD Sites & Replication

Practice configuring sites, subnets, and replication in both GUI and PowerShell.

GUI Lab Tasks

  • Create new AD sites
  • Configure subnets and associations
  • Create and modify site links
  • View replication topology
  • Force replication manually

PowerShell Lab Tasks

  • Create sites with New-ADReplicationSite
  • Configure subnets via PowerShell
  • Manage site links and costs
  • Check replication status
  • Troubleshoot with repadmin
Scenario: Hexworth Corporation is expanding to a new branch office. Configure the AD site infrastructure to ensure optimal authentication and replication.
Start GUI Lab Start PowerShell Lab
A→B + B→C means A→C automaticallyTransitivity
Course Home