Active Directory sites and replication

When a company opens a second office, its DCs can’t all sit in one building any more. Active Directory replication between sites is what keeps every DC’s copy of the directory in step, while sending as little traffic as possible over slower links.

In this lesson you’ll turn the lab into two sites, HQ and Branch, give each its subnets, move DC02 to the branch, connect them with a site link, watch and force replication with repadmin, and break it twice. You’ll also see where read-only DCs fit.

TimeYou needBy the end you can
About 75 minutesDC01, DC02 and CL01 from Phase 2Create sites, subnets and site links, move a DC between sites, read repadmin output, force replication, and diagnose RPC and site-mapping problems

What it is, in one line

Active Directory replication is the process that copies changes (new users, password resets, group changes) from the DC where they were made to every other DC, inside a site quickly and between sites on a schedule.

In Simple Words

Two school offices sharing one register

A school has two buildings, each with its own office and its own copy of the student register. When a new student joins at one office, the other office’s copy must be updated too.

Inside one building, the secretaries just shout the change across the room, straight away. Between buildings, someone walks over with the day’s changes every 15 minutes, so they aren’t running back and forth all day.

AD works the same way: fast within a site, on a schedule between sites. Sites tell AD which DCs are “in the same room”.

Engineer's View

Sites, KCC, USNs and RODCs

Sites and subnets: a site is a set of well-connected subnets. Subnet objects map client IP addresses to sites, so clients find DCs in their own site; the most specific subnet wins. Each DC belongs to the site its server object sits in.

Topology: the Knowledge Consistency Checker (KCC) on every DC builds connection objects automatically: a ring within a site, and through a bridgehead DC between sites. Site links have a cost (lower is preferred) and a replication interval (default 180 minutes, minimum 15).

How changes flow: intra-site replication is triggered about 15 seconds after a change; inter-site follows the link schedule and is compressed. Each DC tracks changes with update sequence numbers (USNs) and the up-to-dateness vector, so only new changes are sent. Account lockouts and some security changes replicate urgently, and password changes go to the PDC Emulator straight away.

RODCs: read-only DCs for branches with weak physical security hold no passwords except those you allow to be cached (Password Replication Policy), accept no changes, and can be managed by local branch staff without Domain Admin rights.

How it works, step by step

How a change made at HQ reaches the branch:

Active Directory replication: a change travels from DC01 at HQ to DC02 in Branch

Within HQ the change spreads in seconds. Between sites it waits for the next 15-minute slot on the site link, unless you force it, which you’ll do with repadmin.

The site layout you’ll build:

Active Directory replication lab sites: HQ, Branch, HQ-Branch site link and tools
  1. Rename Default-First-Site-Name to HQ and give it the 10.0.0.0/24 subnet.
  2. Create Branch with more specific subnets: 10.0.0.11/32 (DC02) and 10.0.0.128/26 (where CL01’s 10.0.0.150 lives).
  3. Link the sites with HQ-Branch, cost 100, every 15 minutes.
  4. Move DC02’s server object to Branch.
  5. Check clients and replication with nltest and repadmin.

In a real company the branch would be a different network. Using a more specific subnet inside the lab’s single network gives the same behaviour.

Hands-on Lab: Active Directory replication between two sites

Start DC01, DC02 and CL01. Work on DC01 as SAATLAB\adm.rahul in PowerShell as administrator.

1Rename the default site and add its subnet

On DC01:

Get-ADReplicationSite -Filter * | Select-Object Name
Rename-ADObject (Get-ADReplicationSite 'Default-First-Site-Name').DistinguishedName -NewName HQ
New-ADReplicationSubnet -Name '10.0.0.0/24' -Site HQ -Location 'Head office'
Get-ADReplicationSite -Filter * | Select-Object Name

You should see something like this:

Name
----
Default-First-Site-Name

Name
----
HQ

Renaming the default site is safe and common. Every DC and site link that referenced it follows the rename, because AD links objects by their identity, not their name.

✅ Checkpoint: The only site is now called HQ and it owns the 10.0.0.0/24 subnet.

2Create the Branch site, its subnets and a site link

On DC01:

New-ADReplicationSite -Name Branch -Description 'Branch office'
New-ADReplicationSubnet -Name '10.0.0.11/32' -Site Branch -Location 'Branch DC'
New-ADReplicationSubnet -Name '10.0.0.128/26' -Site Branch -Location 'Branch clients'
New-ADReplicationSiteLink -Name 'HQ-Branch' -SitesIncluded HQ, Branch -Cost 100 -ReplicationFrequencyInMinutes 15 -InterSiteTransportProtocol IP
Get-ADReplicationSubnet -Filter * | Select-Object Name, @{n='Site';e={($_.Site -split ',')[0] -replace 'CN='}}
Get-ADReplicationSiteLink -Filter * | Select-Object Name, Cost, ReplicationFrequencyInMinutes

You should see something like this:

Name          Site
----          ----
10.0.0.0/24   HQ
10.0.0.11/32  Branch
10.0.0.128/26 Branch

Name              Cost ReplicationFrequencyInMinutes
----              ---- -----------------------------
DEFAULTIPSITELINK  100                           180
HQ-Branch          100                            15

DEFAULTIPSITELINK still contains only HQ. HQ-Branch is the link replication will use, every 15 minutes instead of the default 180.

✅ Checkpoint: Three subnets exist, two in Branch, and HQ-Branch replicates every 15 minutes.

3Move DC02 to the Branch site

On DC01:

Move-ADDirectoryServer -Identity DC02 -Site Branch
Get-ADDomainController -Filter * | Select-Object Name, IPv4Address, Site

You should see something like this:

Name IPv4Address Site
---- ----------- ----
DC01 10.0.0.10   HQ
DC02 10.0.0.11   Branch

Restart DC02 (or wait) so its Netlogon service re-registers DNS records for the Branch site, such as _ldap._tcp.Branch._sites.dc._msdcs.saatlab.internal. Clients in Branch use those records to find DC02 first.

After DC02 restarts, on DC01:

Resolve-DnsName -Type SRV _ldap._tcp.Branch._sites.dc._msdcs.saatlab.internal | Select-Object NameTarget

You should see something like this:

NameTarget
----------
DC02.saatlab.internal

✅ Checkpoint: DC02 shows Site Branch, and the Branch SRV record points to DC02.

4Check which site and DC CL01 uses

On CL01 (any user), restart Netlogon as admin or just restart CL01, then:

nltest /dsgetsite
nltest /dsgetdc:saatlab.internal | Select-String 'DC:|Dc Site Name|Our Site Name'

You should see something like this:

Branch
The command completed successfully
           DC: \\DC02.saatlab.internal
 Dc Site Name: Branch
Our Site Name: Branch

CL01’s address 10.0.0.150 falls in 10.0.0.128/26, the most specific match, so it’s in Branch and picks DC02. If DC02 went down, CL01 would fall back to a DC in another site.

✅ Checkpoint: CL01 reports site Branch and uses DC02.

Active Directory replication lab: CL01 in the Branch site using DC02
CL01 maps to Branch by its address and picks DC02, the DC in its own site.

5Watch and force replication

On DC01, look at the connections the KCC built and DC02’s inbound replication:

repadmin /kcc DC02
Get-ADReplicationConnection -Filter * -Server DC02 | Select-Object @{n='From';e={($_.ReplicateFromDirectoryServer -split ',')[1] -replace 'CN='}}, AutoGenerated
repadmin /showrepl DC02

You should see something like this (shortened):

From AutoGenerated
---- -------------
DC01          True

Branch\DC02
DSA Options: IS_GC
Site Options: (none)
...
==== INBOUND NEIGHBORS ======================================

DC=saatlab,DC=internal
    HQ\DC01 via RPC
        DSA object GUID: 5b1f...
        Last attempt @ 2026-10-19 22:51:12 was successful.

Now create a user on DC01 and push it to DC02 without waiting 15 minutes:

New-ADUser -Name 'Site Test' -SamAccountName site.test -Path 'OU=Sales,OU=Staff,OU=SAATLAB,DC=saatlab,DC=internal'
Get-ADUser site.test -Server DC02 -ErrorAction SilentlyContinue | Select-Object Name
repadmin /syncall DC01 /AdeP
Get-ADUser site.test -Server DC02 | Select-Object Name

You should see something like this:

CALLBACK MESSAGE: The following replication is in progress:
    From: 5b1f...._msdcs.saatlab.internal
    To  : 9e2c...._msdcs.saatlab.internal
CALLBACK MESSAGE: The following replication completed successfully:
...
CALLBACK MESSAGE: SyncAll Finished.
SyncAll terminated with no errors.

Name
----
Site Test

The first lookup on DC02 returned nothing because the change hadn’t crossed the site link yet. /syncall with /AdeP pushes (P) all partitions (A) across sites (e) by DN (d). Remove the test user afterwards with Remove-ADUser site.test -Confirm:$false.

✅ Checkpoint: site.test was missing on DC02, then present after repadmin /syncall finished with no errors.

Break It, Then Fix It

Two replication problems you’ll meet in real networks: a DC that can’t be reached, and clients whose address belongs to no site.

1Break it: a DC that doesn’t answer

Shut down DC02. On DC01, try to push changes:

repadmin /syncall DC01 /AdeP

You’ll get an error like this:

SyncAll reported the following errors:
Error issuing replication: 1722 (0x6ba):
    The RPC server is unavailable.
    From: CN=NTDS Settings,CN=DC01,CN=Servers,CN=HQ,CN=Sites,CN=Configuration,DC=saatlab,DC=internal
    To  : CN=NTDS Settings,CN=DC02,CN=Servers,CN=Branch,CN=Sites,CN=Configuration,DC=saatlab,DC=internal

And the summary view:

repadmin /replsummary

You’ll see something like this:

Source DSA          largest delta    fails/total %%   error
 DC01                      08m:41s    5 /   5  100  (1722) The RPC server is unavailable.

Destination DSA     largest delta    fails/total %%   error
 DC02                      08m:41s    5 /   5  100  (1722) The RPC server is unavailable.

1722 means DC01 couldn’t reach DC02 over RPC at all: the server is down, a firewall blocks RPC (TCP 135 plus dynamic ports), or DNS points to the wrong address. It’s the most common replication error. Check, in order: is it up, does its name resolve, can you reach it (Test-NetConnection DC02 -Port 135).

Fix it: start DC02, then sync and check again:

repadmin /syncall DC01 /AdeP
repadmin /replsummary

✅ Checkpoint: replsummary showed 1722 while DC02 was off and 0 failures after it started and synced.

Active Directory replication lab: replsummary error 1722 RPC server unavailable
With DC02 down, every partition fails with 1722.

2Break it: clients in no site

On DC01, remove both subnets that cover CL01:

Remove-ADReplicationSubnet '10.0.0.128/26' -Confirm:$false
Remove-ADReplicationSubnet '10.0.0.0/24' -Confirm:$false

On CL01, as administrator, make Netlogon look up its site again:

Restart-Service Netlogon
nltest /dsgetsite

You’ll get an error like this:

Getting DC Site failed: Status = 1919 0x77f ERROR_NO_SITENAME

CL01 now belongs to no site, so it may pick any DC in the domain, even one across a slow link. DCs record this in the System log as NETLOGON event 5807, listing client addresses that don’t map to a site. In large companies, new office subnets that nobody added to AD cause exactly this.

Fix it: recreate the subnets, then restart Netlogon on CL01:

New-ADReplicationSubnet -Name '10.0.0.0/24' -Site HQ -Location 'Head office'          # on DC01
New-ADReplicationSubnet -Name '10.0.0.128/26' -Site Branch -Location 'Branch clients'  # on DC01
Restart-Service Netlogon; nltest /dsgetsite                                            # on CL01

✅ Checkpoint: CL01 reported ERROR_NO_SITENAME without subnets and Branch again after recreating them.

This happened at work

The DC that came back from the dead

A company closed a small office and shut its DC down in a cupboard, intending to decommission it properly “later”. Seven months later, someone found it, plugged it back in and switched it on.

The DC hadn’t replicated for longer than the tombstone lifetime (180 days). Its partners refused to replicate with it and logged event 2042: “It has been too long since this machine last replicated with the named source machine.” Worse, it held objects deleted elsewhere months earlier, which could have come back to life as lingering objects.

The team didn’t try to force it back. They removed its metadata from AD with ntdsutil metadata cleanup, wiped the server, and checked the other DCs with repadmin /removelingeringobjects in advisory mode.

The fix: a decommissioning checklist (demote, then clean up, never just switch off), and monitoring that alerts when any DC hasn’t replicated for 24 hours.

The lesson: a DC offline past the tombstone lifetime must never rejoin. Demote DCs properly, and watch replication every day.

Common mistakes and troubleshooting

Mistake or symptomWhat happensWhat to do instead
Error 1722 RPC server unavailableDCs can’t replicateCheck the DC is up, DNS, and TCP 135 plus dynamic RPC ports
Subnets missing for new officesClients use distant DCs; event 5807Add every subnet to a site
Leaving the default 180-minute intervalBranch changes take hoursShorter intervals where links allow
Manually created connection objects everywhereThe KCC can’t adapt to failuresLet the KCC manage connections
Switching off a DC instead of demoting itMetadata left behind; risk of rejoin past tombstoneDemote, then metadata cleanup if needed
DC offline more than 180 days rejoiningLingering objects, event 2042Never reconnect; clean up and rebuild
Writable DC in an insecure branchTheft exposes every password hashRODC with a tight Password Replication Policy
Not monitoring replicationProblems found weeks laterDaily repadmin /replsummary or monitoring alerts
Firewalls between sites blocking RPCReplication fails silently between sitesOpen AD ports between DCs, or use a fixed RPC port

Interview questions

Click a question to open it. Under each one you’ll find what the interviewer is really looking for, and one good way to answer.

Fresher level

1. What is an AD site?

What they’re really checking: Do you know the basics?

How you could answer: A group of well-connected subnets. Sites control which DC clients use and how replication is scheduled between locations.

2. What is the difference between intra-site and inter-site replication?

What they’re really checking: Do you understand the two modes?

How you could answer: Intra-site happens within seconds of a change, uncompressed. Inter-site follows site link schedules and intervals, compressed, through bridgehead servers.

3. Which command shows replication health quickly?

What they’re really checking: Have you used repadmin?

How you could answer: repadmin /replsummary for an overview of failures and largest deltas; repadmin /showrepl for details per partner and partition.

2–5 years experience

4. What does error 1722 mean in replication?

What they’re really checking: Can you diagnose a common error?

How you could answer: The RPC server is unavailable: the partner DC is down, unreachable through firewalls, or DNS resolves it wrongly. Check name resolution, ports 135 and dynamic RPC, and the DC itself.

5. What is the KCC?

What they’re really checking: Do you know topology generation?

How you could answer: The Knowledge Consistency Checker builds replication connection objects automatically, rebuilding them when DCs or sites change.

6. What happens when a client’s IP isn’t in any subnet?

What they’re really checking: Do you understand site mapping?

How you could answer: It has no site, may use any DC, and DCs log event 5807. Add the subnet to the right site.

Senior level

7. Design AD sites for a company with HQ, two regional offices and 30 small shops.

What they’re really checking: Do you think about scale?

How you could answer: Sites for HQ and regions with DCs, site links with costs that match the WAN, shops either in the nearest regional site or with RODCs if local auth is needed, all subnets mapped, and monitoring of replication and site coverage.

8. What are lingering objects and how do you deal with them?

What they’re really checking: Do you know advanced recovery?

How you could answer: Objects deleted on other DCs that survive on a DC that missed the deletion past the tombstone lifetime. Prevent with strict replication consistency, detect and remove with repadmin /removelingeringobjects, and never reconnect stale DCs.

9. When would you deploy an RODC?

What they’re really checking: Do you understand branch security?

How you could answer: In locations with weak physical security or no IT staff, where local sign-in is needed but a stolen DC must not expose all passwords. Configure the Password Replication Policy and delegated RODC admins.

Quick quiz

Q1. How does a client know which site it’s in?

  1. From its computer name
  2. Its IP address matches a subnet linked to a site
  3. From the user account
Show answer

B — The most specific subnet wins.

Q2. What did repadmin show while DC02 was off?

  1. Error 5
  2. Error 1722 RPC server unavailable
  3. No errors
Show answer

B — The partner couldn’t be reached.

Q3. What does /AdeP do with repadmin /syncall?

  1. Deletes partitions
  2. Pushes all partitions across sites
  3. Shows errors only
Show answer

B — A all, d DN, e enterprise, P push.

Q4. What did nltest /dsgetsite return with no subnets?

  1. HQ
  2. ERROR_NO_SITENAME
  3. Branch
Show answer

B — Clients in no site may use any DC.

Q5. In the work story, why couldn’t the old DC rejoin?

  1. Its password expired
  2. It had been offline past the tombstone lifetime
  3. Its disk failed
Show answer

B — Demote, clean up and rebuild instead.

Quick recap

  • Active Directory replication copies changes between DCs: seconds within a site, on schedule between sites.
  • Sites are groups of subnets; clients use the most specific subnet to find their site.
  • Site links have costs and intervals; the KCC builds connections automatically.
  • repadmin /replsummary, /showrepl and /syncall /AdeP are your daily tools.
  • 1722 means the partner can’t be reached; 5807 means clients without a site.
  • Never reconnect a DC offline past the tombstone lifetime; use RODCs in insecure branches.

Next lesson

Lesson 32: AD backup and recovery → You’ll back up a DC’s system state, restore a deleted OU authoritatively in DSRM, seize an FSMO role from a dead DC and clean up its metadata.

Further reading: Active Directory replication

Want to go deeper into Active Directory replication? Microsoft’s common AD replication errors page explains each error code, and the replication and topology with PowerShell guide covers the cmdlets used here. You can also see the full plan for this course on the Windows Server Administration course page.

Scroll to Top