repadmin is the tool that answers one question no GUI answers quickly: is every domain controller in this forest actually receiving the changes the others make? It reads replication metadata straight from AD DS, so it reports what the directory believes, not what a console has cached.
Most administrators meet it during an incident. A password reset that works on one site and not another, a group membership that never reaches a file server, a decommissioned DC that still appears in DNS. All of those trace back to replication, and all of them are visible in repadmin output within about thirty seconds if you know which two subcommands to run first.
The official reference lists every subcommand and every switch. What it does not do is tell you which numbers matter, which failures are cosmetic, or when forcing replication is the wrong move. That is what this page covers. If you are looking for the broader health tests rather than replication specifically, the dcdiag guide is the companion piece.
Applies to: Windows Server 2016 / 2019 / 2022 / 2025 with the AD DS role, or any machine with RSAT installed
Quick answer
Two commands cover the first minute of almost every replication investigation. The first gives you a forest-wide summary, the second names the exact partner and partition that is failing.
rem Forest-wide summary, sorted so the worst offender is at the top
repadmin /replsummary /bysrc /bydest /sort:delta
rem Every failing inbound connection on every DC, nothing else
repadmin /showrepl * /errorsonlyRun both from an elevated prompt on any domain controller, or from a workstation with RSAT. Neither one changes anything.
What repadmin does
Active Directory replication is a pull model. A destination DC asks a source DC for changes it has not seen yet, tracked by update sequence numbers and an up-to-dateness vector. repadmin is a client for that bookkeeping. Every subcommand reads or triggers part of it.
These are the subcommands worth knowing. The rest of the surface area exists for lingering object cleanup and RODC password policy work, which are separate topics.
| Subcommand | What it reports or does | Read or write |
|---|---|---|
/replsummary | Per-DC roll-up of failures and how stale each DC is | Read |
/showrepl | Per-partition inbound replication status and last error | Read |
/queue | Inbound replication requests still waiting to be processed | Read |
/showutdvec | Highest USN this DC has committed from each partner | Read |
/showobjmeta | Per-attribute version, timestamp and originating DC for one object | Read |
/syncall | Synchronises a DC with its partners now | Write |
/replicate | Replicates one partition between one named pair of DCs | Write |
/kcc | Forces the Knowledge Consistency Checker to recalculate topology | Write |
* in repadmin /showrepl * is not a wildcard for partitions. It is the DSA list, and it means “every domain controller in the forest”. Leave it out and you get the local DC only.
Practical examples
1. Is replication healthy at all?
The problem: A helpdesk ticket says a password reset done on SRV-DC01 was rejected twenty minutes later at a branch site. You need to know whether this is one broken link or a forest that has been drifting for weeks.
The solution: /replsummary collapses every source and destination pair into one table, so a systemic problem and a single bad link look completely different.
rem /bysrc and /bydest print both directions, which matters when only one way is broken
rem /sort:delta puts the least current DC first, so the worst case is line one
repadmin /replsummary /bysrc /bydest /sort:deltaThe output has two blocks. Largest delta is the time since that DC last replicated successfully, fails/total is the failure count against attempts, and the last column carries the error that is blocking it.
Source DSA largest delta fails/total %% error
SRV-DC01 :07:22 0 / 10 0
SRV-DC02 :12:05 0 / 10 0
SRV-DC-BR1 15d.03h:11m 5 / 5 100 (1256) The remote system is not available.
Destination DSA largest delta fails/total %% error
SRV-DC-BR1 15d.03h:11m 5 / 5 100 (1256) The remote system is not available.One DC at fifteen days and everything else under fifteen minutes is a connectivity problem at one site, not a directory problem. That distinction decides who you call next.
2. Which partner and which partition is failing?
The problem: The summary named SRV-DC-BR1, but a DC replicates several partitions from several partners. You need the specific pairing before you can test anything.
The solution: /showrepl reports inbound status per partition per partner, and /errorsonly strips out everything that is working.
rem Only the broken connections, across the whole forest
repadmin /showrepl * /errorsonly
rem The same data as CSV when you want to sort or keep it with the ticket
repadmin /showrepl * /csv > C:\logs\repl.csvOn a machine with the AD PowerShell module, Microsoft documents a nicer way to read the CSV without opening Excel.
# Pipes the CSV straight into a sortable, filterable grid
repadmin /showrepl * /csv | ConvertFrom-Csv | Out-GridViewSort that grid by Last Failure Status. The error code is the actual lead. 1256 and 1722 point at the network or RPC, 8453 at permissions, 8524 at DNS resolution of the partner GUID, and 8606 at lingering objects.
_msdcs.<forest>, so a missing or stale record there breaks replication while ping by hostname still works. The nslookup guide covers how to query those records directly.
3. A change is not appearing on another DC
The problem: You added a user to a group on SRV-DC01 and the branch site still refuses access. Nothing is failing, the change simply has not arrived yet.
The solution: /syncall pushes the change out immediately instead of waiting for the schedule. The flags are where people get this wrong, so they are worth spelling out.
rem A = all naming contexts held by this DC, not just the configuration partition
rem d = report partners by distinguished name, which makes the output readable
rem e = cross site boundaries, otherwise only the local site is touched
rem P = push changes outward from this DC instead of pulling into it
repadmin /syncall SRV-DC01 /AdeP/e the command stops at the site boundary, and without /P it pulls into the named DC rather than pushing out of it. Both omissions look like success in the output and change nothing at the remote site.
When you only care about one partition and one pair of DCs, /replicate is the narrower instrument and finishes faster on a large domain.
rem Destination first, then source, then the partition to pull
repadmin /replicate SRV-DC-BR1 SRV-DC01 dc=corp,dc=local4. Which DC last changed this attribute?
The problem: A service account password changed at 02:00 and nobody admits to it. The security log on the DC you are standing in front of shows nothing, because the change did not originate there.
The solution: Replication metadata records, for every attribute, the version number, the time it was written and which DC wrote it. /showobjmeta is the only built-in way to read it.
repadmin /showobjmeta SRV-DC01 "CN=svc-backup,OU=Service Accounts,DC=corp,DC=local"Loc.USN Originating DSA Org.USN Org.Time/Date Ver Attribute
======= =============== ======= ============= === =========
14992 Default-First-Site-Name\SRV-DC02 14992 2026-09-03 02:14:07 9 unicodePwd
14992 Default-First-Site-Name\SRV-DC02 14992 2026-09-03 02:14:07 9 pwdLastSet
8104 Default-First-Site-Name\SRV-DC01 8104 2026-04-11 09:31:52 1 sAMAccountNameOriginating DSA names the DC where the change was made, so that is the machine whose security log is worth pulling. The version column is a useful sanity check too: an attribute at version 9 has been rewritten eight times since the object was created.
5. Replication is slow rather than broken
The problem: Nothing reports an error, but changes take hours to appear. This is the pattern after a bulk import, a large group membership change, or a DC that has just come back from a long outage.
The solution: /queue shows what a DC still has to fetch. A queue that is draining is fine. A queue that keeps growing across several runs is not.
rem Run it two or three times a minute apart and compare the depth
repadmin /queue SRV-DC-BR1
rem How far behind each partner this DC actually is, in USN terms
repadmin /showutdvec SRV-DC-BR1 dc=corp,dc=localHidden gems
Running it on the healthy DC tells you nothing. repadmin /showrepl with no DSA list reports inbound status for the machine you are logged into. If you are on the DC that works, the output is clean and the problem is invisible. Always add *, or name the suspect DC explicitly.
Inbound and outbound fail differently. A DC can pull perfectly and still fail to serve its partners. /replsummary /bysrc /bydest shows both directions in one pass, which is why it beats reading /showrepl DC by DC when you do not yet know where the fault is.
/kcc is not a fix. It forces the topology to be recalculated, which helps after adding or removing a DC or changing site links. It does nothing for a connection that is failing on RPC or DNS, and running it during an incident mostly wastes a minute.
Combine it with dcdiag rather than choosing between them. dcdiag /test:Replications tells you a component failed; repadmin /showrepl * /errorsonly tells you which link, which partition and which error code. Run the first to confirm, the second to act.
PowerShell equivalent
The ActiveDirectory module covers the read side properly, and returns objects instead of text, which makes it the better choice for scheduled checks and reports.
# Every replication failure in the forest, as objects you can filter and export
Get-ADReplicationFailure -Target corp.local -Scope Forest
# Per-partner metadata including LastReplicationSuccess, the PowerShell answer to /showrepl
Get-ADReplicationPartnerMetadata -Target corp.local -Scope Domain |
Select-Object Server, Partner, LastReplicationSuccess, LastReplicationResult
# The /showobjmeta equivalent, including who wrote each attribute
Get-ADReplicationAttributeMetadata -Object "CN=svc-backup,OU=Service Accounts,DC=corp,DC=local" -Server SRV-DC01
# Push one object to one DC without triggering a full partition sync
Sync-ADObject -Object "CN=svc-backup,OU=Service Accounts,DC=corp,DC=local" -Source SRV-DC01 -Destination SRV-DC-BR1Sync-ADObject replicates a single object rather than a partition. For one urgent group membership change across a WAN link it is far cheaper than repadmin /syncall.
Where this matters
- After promoting a new DC. Initial sync of every partition is the acceptance test.
repadmin /showrepl SRV-DC-NEWmust be clean for the Domain, Configuration and Schema partitions before the machine carries production load. - Before demoting one. Outbound replication has to be healthy or changes that only exist on that DC are lost when it leaves.
- Trust relationship failures. A machine account password reset that never replicates produces exactly the symptoms described in the trust relationship guide, on some DCs and not others.
- Group Policy that applies inconsistently. GPO content lives in SYSVOL and GPO metadata lives in AD. When the two are out of step, the version numbers in
/showobjmetaon the GPC object show which side is behind. - After a site link or firewall change. Replication is the first thing to break and the last thing anyone checks.
Tips and limitations
- Read subcommands need Domain Admins or delegated replication rights. Write subcommands such as
/syncalland/kccneed an elevated prompt as well. repadminships with the AD DS role and with RSAT. On a workstation, install the Active Directory Domain Services tools feature before expecting it on the path.- Time skew breaks replication indirectly through Kerberos. If replication fails with 8453 across several partners at once, check time synchronisation with w32tm before anything else.
/showreplreports inbound only. To see who pulls from a DC, add/repsto, or use/allfor both that and the KCC connection objects.- Deltas measured in minutes are normal. Intra-site replication is notification driven with a short delay, and inter-site replication follows the site link schedule, which defaults to 180 minutes.
- The Directory Service event log is the other half of the story. Events 1311, 1865, 1988 and 2042 describe topology, connectivity and lingering object problems that
repadminreports only as an error number.
Official documentation
- Repadmin subcommand reference | Microsoft Learn
- Diagnose Active Directory replication failures | Microsoft Learn
Related tools
- nltest Command Builder: builds the secure channel and DC discovery commands you reach for once replication points at one specific domain controller.
- DNS Lookup Tool: checks the SRV and CNAME records under
_msdcsthat replication error 8524 usually turns out to be about. - Windows Event Log Analyzer: for reading the Directory Service log entries that sit behind a bare replication error code.
Related guides
- Active Directory Troubleshooting Cheat Sheet: every command on this page, plus the rest of the AD toolkit, on one printable sheet.
- klist in Windows: read and clear the Kerberos ticket cache: for checking whether the group change that replicated is actually in the user ticket yet.
- DCDiag: how to diagnose and fix Active Directory problems: the health test suite that tells you a component failed, where repadmin tells you which link failed.
- nltest command in Windows: domain controller discovery and trust diagnostics: the next step once you know which DC is unreachable.
- How to fix the trust relationship between a workstation and the domain: the failure mode that unreplicated machine account passwords produce.
- w32tm in Windows: diagnose and fix domain time synchronisation: the clock skew that produces replication error 8453 across several partners at once.
- dsquery and dsget: querying Active Directory from the command line: for finding the distinguished names that repadmin subcommands expect as arguments.