Password Changes Not Replicating Between Sites

Introduction

A user resets their password at the help desk’s request on a Monday morning, sitting at a desk in the head office. They log off, log back on with the new password, and get straight in. Ticket closed.

Tuesday, the same user is at a branch office two hundred miles away, on a domain controller that has never been anywhere near the one that processed the change. They type the same new password. Access denied. They type it again, carefully. Still denied. The help desk re-opens the ticket, half-convinced the user has simply forgotten what they typed a day earlier.

They have not. The password is correct. The branch domain controller just does not know that yet.

What You’re Seeing

The symptom rarely comes with a distinctive error code of its own. It looks exactly like a mistyped password, which is exactly why it gets misdiagnosed as one. On the logon screen: “The user name or password is incorrect.” In the branch domain controller’s Security log, a matching Event ID 4625 with Sub Status 0xC000006A. Microsoft’s own documentation for that event lists 0xC000006A as “User logon with misspelled or bad password.”

That sub status is the clue that separates this from a connectivity problem. It is not the same failure as There Are Currently No Logon Servers Available, which is Sub Status 0XC000005E and means the machine could not find or reach any domain controller at all. Here, the domain controller was found, was reached, and answered. It simply disagreed about the password.

If the branch domain controller is running Windows Server 2022 or later, there is a second, more direct clue on the PDC emulator itself. Under Directory Service event logging category “27 PDC Password Update Notifications”, a failed forward from the branch DC shows up as Event ID 3038: “Active Directory Domain Services failed to send a password update notification to the Primary Domain Controller (PDC).” That event, when present, tells you exactly where the chain broke, and its description even names the fallback: normal replication schedules.

What’s Actually Happening

Think of the PDC emulator as the one phone number every branch office is trained to call before turning someone away at the door. Most of the time, that call is enough: the branch does not need the full, up-to-date membership list itself, because it can simply ask the one office that already has it. The membership list still gets couriered around to every branch on its normal schedule, but the phone call is what keeps the door working in the meantime.

Concretely: when a domain controller processes a password change, it makes the change locally and then sends it immediately to the PDC FSMO role holder over a Netlogon RPC call. This happens regardless of the site link schedule, because it is a direct call to a specific DC, not a wait for a replication cycle. Both that domain controller and the PDC then include the new password in their own outbound replication to their normal partners, which is where ordinary AD replication timing takes over.

This is also why the branch office usually never notices anything happened. If a domain controller receives a logon attempt with what it thinks is a wrong password, by default it does not just reject it: it asks the PDC emulator first. If the PDC already has the new password (because the originating DC already phoned it in), the logon succeeds, and the branch DC replicates the fresh password for itself immediately afterwards. The user never sees a failure. This fallback is controlled by a registry value called AvoidPdcOnWan, and it is on by default, which is precisely why cross-site password problems are the exception rather than the daily norm.

The failure mode in this post is what happens when that phone call cannot be made, or was never answered. The user is then relying entirely on ordinary replication to carry the new password to the branch domain controller, and ordinary replication is not urgent. Inside a single site, change notification kicks off roughly 15 seconds after a change and propagates to further partners a few seconds after that. Between sites, replication follows the site link’s own schedule, with a default interval of 180 minutes and a configurable minimum of 15 minutes, unless that link has been explicitly set to use inter-site change notification instead.

Put those two facts together and the branch office’s wait for a password it should already have can run from a few minutes to a few hours, depending entirely on how that site link is configured: a very different experience from the “instant” cross-site behaviour everyone has come to expect.

How to Diagnose It

Work from cheapest check to deepest. Most of the time the answer is visible within the first two or three commands.

# Confirm which DC actually holds the PDC emulator role
netdom query fsmo

# From the affected branch DC, check for inbound replication errors
repadmin /showrepl dc02-branch /errorsonly

# Forest-wide summary of replication health, sorted by largest delay
repadmin /replsummary * /bysrc /bydest /sort:delta

# Check how much unprocessed inbound work the branch DC is carrying
repadmin /queue dc02-branch

# Check the inter-site link's replication interval and whether
# change notification is enabled between the two sites
Get-ADReplicationSiteLink -Filter * -Properties ReplicationFrequencyInMinutes,Options | Format-Table Name,ReplicationFrequencyInMinutes,Options -AutoSize

# On the branch DC, confirm whether PDC fallback has been disabled
reg query "HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" /v AvoidPdcOnWan

If normal replication itself is unhealthy, this stops being a password-specific problem and becomes a general replication problem wearing a password-shaped costume, worth ruling out early with AD Replication Error 1722 if the RPC server is genuinely unreachable.

Common Causes

The Fix

Start by confirming the PDC emulator’s identity and reachability, since almost every branch of this problem traces back to that one DC.

# Identify the PDC emulator
netdom query fsmo

# Confirm the branch DC can reach the PDC's site over ordinary replication
repadmin /showrepl dc02-branch /errorsonly

If replication to the PDC’s site is genuinely broken, that is the real incident. Fix the network or firewall path first, and the password issue resolves itself once replication catches up. If replication is healthy but slow because of a long site link interval, and the user cannot simply wait, force it directly rather than waiting out the schedule:

# Push the branch DC's outstanding changes out across all sites now
repadmin /syncall dc02-branch dc=corp,dc=example,dc=com /d /e /a

If AvoidPdcOnWan is the culprit, removing it restores the fallback that was masking most of these delays in the first place, and it takes effect without a reboot once the Netlogon service picks up the change. Restarting Netlogon on the branch DC is the safe way to force that immediately in a maintenance window.

How to Prevent It

The default configuration already does most of the work: PDC fallback is on unless someone has turned it off, and that alone hides the vast majority of cross-site password timing. The remaining work is keeping the two mechanisms underneath it healthy.

Treat AvoidPdcOnWan as an explicit, documented decision rather than something that gets set once during a WAN-cost exercise and forgotten. It directly controls whether users get the safety net this whole post is about. For sites where password changes are frequent and the link is fast enough to absorb it (onboarding-heavy sites, or branches close enough to be effectively LAN-speed), enabling inter-site change notification on that link removes the site link schedule from the equation entirely for every change, not just passwords.

Beyond that, this is fundamentally a replication health problem wearing a password mask, so the same habit that catches most AD trouble catches this too: check repadmin /replsummary regularly and treat any DC with a growing delta as an incident before a user notices. The Active Directory — Part 7 — Active Directory Replication post covers that habit in full, and the Active Directory — Part 10 — Account Lockouts & Password Policies post covers the closely related case where it is a lockout, not a password change, chasing the PDC emulator around the domain.

Final Thoughts

Cross-site password failures feel like a user problem right up until you check the sub status code and realise the domain controller genuinely does not have the password yet. The PDC emulator is doing exactly what it is designed to do. It is the fallback that is missing, not the password.

Once you know to check AvoidPdcOnWan, the reachability of the PDC emulator, and the site link’s own interval, the diagnosis usually takes minutes. The part worth remembering is the one most people get backwards: password changes are fast because of a direct call to one DC, not because Active Directory treats them as urgent replication in the formal sense.