How to Force Active Directory Replication Between Domain Controllers

Active Directory replicates on its own schedule, and most of the time that’s exactly what you want — you don’t want to babysit it. But there are moments when waiting isn’t an option. You’ve reset a locked-out user’s password and they need it on their site’s DC now. You’ve edited a GPO and want it on every DC before testing. You’ve fixed a replication fault and want to confirm changes flow again. For all of those, you force replication instead of waiting for the timer.

This guide covers the three ways to push replication on demand: repadmin /syncall from the command line, Replicate Now in Active Directory Sites and Services, and the PowerShell equivalents. Then it shows how to check that the sync actually landed, because forcing a sync and assuming it worked is how people get caught out.

When you actually need to force replication#

By default, replication is quick within a site and slower between sites. Knowing the normal timing tells you whether forcing it is even worth doing.

So inside one site you rarely need to force anything — by the time you switch windows the change is usually already there. The case for forcing is almost always between sites, where the default three-hour gap is too long for whatever you’re doing right now.

Method 1: repadmin /syncall (the one to know)#

repadmin is the workhorse for replication. /syncall tells the DC you run it on to synchronize with its partners. The switches control the scope and direction, and the combination you’ll use most is /AdeP:

repadmin /syncall /AdeP

Here’s what each switch means, because using them blindly leads to surprises:

The direction matters. Without P, /syncall pulls changes into the DC you’re on. With P, it pushes this DC’s changes out to everyone. So the choice is about where the change you care about currently lives:

# You made a change on THIS DC and want it everywhere: push outward
repadmin /syncall /AdeP

# You want THIS DC to catch up with everyone else: pull inward
repadmin /syncall /Ade

A successful run ends with a line like SyncAll terminated with no errors. Any per-partner errors are listed with their codes — note them and chase them down rather than ignoring them.

Method 2: Replicate Now in Sites and Services#

If you prefer the GUI, Active Directory Sites and Services does the same job per connection.

1. Open Active Directory Sites and Services (dssite.msc).
2. Expand Sites → your site → Servers → the DC you want to update.
3. Expand NTDS Settings under that server. You’ll see one or more connection objects, each representing an inbound replication partner.
4. Right-click a connection and choose Replicate Now.

This pulls changes from the partner named in the connection into the DC you expanded. To sync the other direction, go to the partner DC’s NTDS Settings and replicate its connection instead — replication connections are one-way, so each direction is a separate object.

If Replicate Now returns “The following error occurred… target principal name is incorrect” or a 1722, that’s a connectivity or trust problem, not a replication scheduling issue — diagnose it as you would any replication failure.

Method 3: PowerShell#

PowerShell can force replication too, which is handy when you’re already scripting or want to target a single object.

To replicate one object (say, an urgent password reset) from one DC to another by distinguished name:

Sync-ADObject `
  -Object "CN=Jane Doe,OU=Staff,DC=ad,DC=example,DC=com" `
  -Source "DC01" `
  -Destination "DC02"

repadmin also has a single-object mode that does the same thing from the command line:

repadmin /replsingleobj DC02 DC01 "CN=Jane Doe,OU=Staff,DC=ad,DC=example,DC=com"

For a full sync you can still drive repadmin from PowerShell, or query replication metadata with the Get-ADReplication* family of cmdlets:

# Force a full push from the local DC
repadmin /syncall /AdeP

# Inspect partner status from PowerShell
Get-ADReplicationPartnerMetadata -Target "DC01" -Scope Server |
  Format-Table Partner, LastReplicationSuccess, LastReplicationResult

Verify the sync actually worked#

This is the step people skip. Forcing replication tells the DCs to try; it doesn’t promise they succeeded. Always confirm.

Start with the forest-wide summary. /replsummary gives a compact table of the largest replication delays and any failures per DC:

repadmin /replsummary

You want the “largest delta” column to show recent times (seconds or minutes, not hours or days) and the “fails” column to read zero. Then drill into a specific DC with /showrepl to see the last result and timestamp for every inbound partner and partition:

repadmin /showrepl

A healthy entry shows Last attempt @ <recent time> was successful. A failing one shows an error code and a growing number of consecutive failures — that’s your signal to stop forcing and start diagnosing.

Quick reference#

Wrapping up#

Forcing replication is a small, everyday tool: repadmin /syncall /AdeP to push a change out from the DC you’re on, Replicate Now when you’d rather click, and Sync-ADObject when only one object needs to move. The discipline that separates a quick fix from a confusing afternoon is verification — run /replsummary and /showrepl afterward and confirm the change landed where you expected.

And remember the line between slow and broken. If a forced sync fails rather than just lagging, the problem is connectivity, not timing. Start with replication error 1722, and if you’re moving roles around as part of recovery, see how to transfer or seize FSMO roles.