Active Directory (AD) replication keeps every domain controller (DC) in sync, but it runs on a schedule. A change you just made—a password reset, a new Group Policy Object (GPO), or a disabled account—may take time to reach the other DCs. When a change is urgent, you don't want to wait for the next cycle; you force replication so it propagates immediately.

This guide covers how to force AD replication using the Sync-ADObject PowerShell cmdlet, the repadmin command-line tool, the Active Directory Sites and Services console, and ManageEngine ADManager Plus. It also covers how to verify if forced AD replication worked and troubleshoot common errors you may face.

What is AD replication and when should you force it?

AD replication is the process by which DCs exchange directory changes so that every DC holds a consistent copy of the database. When you change an object on one DC, that change has to reach all the others. Within a single site, DCs use change notification to replicate within about 15 seconds of a change; between sites, replication follows a schedule of 180 minutes by default to conserve WAN bandwidth. That built-in latency is normal, but some situations can't wait for it:

• After a password reset that a user needs to work against a different DC right away.
• After deploying a new GPO you want applied consistently before users log on.
• After promoting or demoting a DC to confirm the topology has converged.
• During disaster recovery to push or pull changes quickly while restoring service.
• After an urgent security change, such as disabling a compromised account that must reach every DC now.

Replication is fundamentally pull-based: a destination DC requests changes from a source DC, usually prompted by a change notification. Forcing replication either tells a destination to pull now, or with the right flag, tells a source to push its changes outward.

How the Knowledge Consistency Checker manages replication topology: You rarely define replication paths by hand. The Knowledge Consistency Checker (KCC), a process that runs on every DC, automatically builds and maintains the replication topology—the set of connection objects that determine which DC replicates with which. It recalculates the topology every 15 minutes by default, creating an efficient ring within a site and using site links to route replication between sites. When you force replication, you're pushing changes along the connections the KCC already created; you're not bypassing the topology, just triggering it on demand.

Prerequisites

Before running any replication command, confirm the environment is ready. Most replication problems trace back to one of these:

• Administrative rights: You need Domain Admins membership, or delegated replication rights, and commands must run from an elevated prompt.
• DC connectivity and DNS: The source and destination DCs must be able to reach each other over the network, and DNS must resolve DC names correctly. Replication rides on remote procedure call (RPC) and depends on name resolution.
• Time synchronization: The Windows Time Service must keep DC clocks within five minutes of each other; Kerberos fails beyond that skew, which blocks replication with an access-denied error.
• Know your DCs: Identify the correct source and destination DCs. List them with nltest /dclist:corp.com or from the Active Directory Sites and Services console.

For the PowerShell method, import the module first with this PowerShell command:

How to force replication using PowerShell

PowerShell's Sync-ADObject is the right tool when you need to push a single object to a specific DC immediately. The classic case being a password reset that a user needs recognized on another DC straight away. It replicates one object from a source DC to a destination DC without waiting for the schedule.

Supply the object's distinguished name, the source DC, and the destination DC:

After a sync, you can confirm replication health for a DC using the AD replication cmdlets. For example, to see the last replication attempt and result per partner, run:

To see any outstanding replication failures for a DC, use Get-ADReplicationFailure:

That gives the per-DC failure list—an empty result means no replication errors are currently recorded for that DC.

Scope note: Sync-ADObject replicates one object at a time, not entire partitions. To force a full, domain-wide sync of all naming contexts, use repadmin /syncall (the second method below).

Supported parameters

The following parameters can be used while syncing AD objects using PowerShell.

How to force replication using the repadmin command-line tool

repadmin is the standard utility for forcing replication across partitions and DCs. Run it from an elevated command prompt on a DC. The two commands you'll use most are /syncall for a full sync and /replicate for a targeted one.

Force domain-wide replication with repadmin /syncall

repadmin /syncall synchronizes the home DC with all of its replication partners. Adding the right flags extends it across every partition and every site:

This pushes all naming contexts from the home DC to every other DC enterprise-wide. The following flags control the scope.

Drop the /P flag to pull changes into the home DC from all partners instead. This is useful when you want one specific DC brought fully up to date.

Force replication for a specific domain controller

To replicate a single partition from one named DC to another, use repadmin /replicate with the destination, the source, and the naming context:

This forces DC2 to pull the corp.com domain partition from DC1 immediately—the targeted equivalent of the Replicate Now action in the GUI below.

How to force replication using Active Directory Sites and Services

If you prefer a graphical method, the Active Directory Sites and Services console forces replication with a right-click:

1. Open Active Directory Sites and Services: Press Win + R, type dssite.msc, and press Enter.
2. Expand Sites and navigate to the site that contains the destination DC.
3. Expand Servers, expand the destination DC, and select NTDS Settings.
4. In the details pane on the right, you'll see the connection objects. Each represents inbound replication from a source DC.
5. Right-click the connection object from the source DC and choose Replicate Now.

The NTDS Settings object holds the connection objects the KCC created for that DC. Because replication is pull-based, Replicate Now pulls changes from the source represented by the connection object into the DC you selected. To replicate in both directions, run it on the connection object under each DC.

Limitations of using native tools to force replication

repadmin, Sync-ADObject, and Active Directory Sites and Services all force replication reliably, but each shows its limits as the environment grows:

• Every method requires signing into a DC with an elevated prompt, so forcing replication means hands-on access to the DCs themselves.
• repadmin and Sync-ADObject are command-line tools, so bulk checks and one-off forces depend on syntax fluency and careful targeting of the right source and destination DCs.
• Verification is a separate manual step. You have to run repadmin /showrepl or /replsummary and read the output yourself; nothing surfaces failing DCs at a glance.
• There's no consolidated, at-a-glance view of replication health across many DCs and sites, and no scheduled monitoring to catch failures before they cause authentication or access problems.
• Native tools give you raw error codes with no built-in explanation or resolution guidance, and no exportable record for auditing or compliance.

How to verify the replication succeeded after forcing it

Forcing replication doesn't confirm it worked, so always verify. From an elevated Command Prompt, run the following command to view the replication status of each partner for a DC:

Healthy output lists each source DC and naming context with a recent last attempt and matching last success timestamp, and no error text. A last attempt that failed, or a success timestamp that lags well behind, points to a problem to chase down.

For a domain-wide picture, run the summary command, where repadmin /replsummary rolls up replication health across all DCs, flagging the largest delays and any failures with their error counts:

For a script-free approach, run the DC Replication Status report in ADManager Plus.

Troubleshooting common AD replication failures

When a forced replication fails, the error code usually points straight at the cause. The most common ones are listed below.

Frequently asked questions