Fix ERROR_BACKUP_CONTROLLER 0x0000024A on Windows Server

Quick answer

You're running a command that only works against the PDC emulator — the one domain controller in your forest that holds the Primary Domain Controller FSMO role. Find that server with netdom query fsmo and run your command against it, or transfer the PDC role to the machine you're on.

Why this error shows up

The PDC emulator role still exists for a reason. Password changes, account lockout propagation, time sync for the domain, and a handful of legacy-compatible operations all get funneled through one DC. Microsoft never removed it because too much stuff depends on a single authoritative source for those tasks. So when you fire off something that needs the PDC — ntdsutil operations, W32Time reconfiguration, some netdom commands, older backup tools, or a script that writes to the PDC's SYSVOL replication path — the DC you're talking to checks its own role holders and throws back ERROR_BACKUP_CONTROLLER if it's not the one you need.

I saw this last week with a client running three DCs. Their monitoring script tried to reset the domain time source from whichever DC answered first. Two out of three times it blew up with 0x24A. The script was fine, the roles were fine — the script just wasn't pinned to the PDC.

The error isn't a sign of corruption. It's AD telling you politely: wrong DC, try again.

Fix it in order

1. Find out which DC actually holds the PDC role

Open an elevated Command Prompt on any domain-joined machine and run:

netdom query fsmo

You'll get five lines. The one you care about is PDC. Note the server name.

Powershell alternative if netdom isn't installed:

Get-ADDomain | Select-Object PDCEmulator

Need the AD module. Import-Module ActiveDirectory first if it's not loaded.

2. Retarget your command to that server

Most tools accept a Server= parameter. For example, ntdsutil:

ntdsutil
roles
connections
connect to server PDC01
quit
quit

Or with a one-liner against the PDC in PowerShell:

Invoke-Command -ComputerName PDC01 -ScriptBlock { w32tm /resync }

If you're running a scheduled task or script, hardcode the PDC name instead of letting AD pick. That eliminates the randomness.

3. Verify the PDC is healthy before you trust it

Before you blame your command, make sure the PDC itself isn't in a weird state. On the PDC:

dcdiag /test:fsmocheck /v
dcdiag /test:netlogons
dcdiag /test:advertising

If any of those fail, fix that first. Pushing more operations at a broken PDC just buries the real problem.

4. If you need to run the operation on the server you're already on, move the PDC role

Sometimes retargeting isn't an option. You're on a branch office DC and the WAN link to the PDC is garbage. In that case, transfer the role to the local server. Clean transfer first:

Move-ADDirectoryServerOperationMasterRole -Identity DC02 -OperationMasterRole PDCEmulator

If the current PDC is dead or unreachable, you'll need to seize it:

Move-ADDirectoryServerOperationMasterRole -Identity DC02 -OperationMasterRole PDCEmulator -Force

Seize only when the old holder is permanently gone. Seizing a live role holder causes split-brain replication and you'll spend a Saturday cleaning it up. I know because I did it once in 2021 and I'm still annoyed about it.

5. Confirm the role moved

netdom query fsmo

PDC should now point to DC02. Give it a minute. AD replication isn't instant, and some clients cache the old PDC for up to 15 minutes.

If that doesn't work

Check DNS. If your DC can't resolve the PDC's SRV record, netdom will lie to you. Run nslookup -type=SRV _ldap._tcp.pdc._msdcs.yourdomain.com and make sure it resolves.
Check the FSMO role registration. Sometimes the role is held but not properly registered. dcdiag /test:knowsofroleholders /v will call it out.
Check time. Kerberos dies if the PDC and the DC you're talking to are more than 5 minutes apart. Run w32tm /query /status on both. If skew is off, fix time sync before anything else.
Check firewalls. Port 135 (RPC endpoint mapper) and the dynamic RPC range need to be open between DCs. Small shop firewalls love blocking that range.
Old backup software. Some legacy tools hardcode expectations about which DC is "the" master and refuse to talk to anything else. Check for a version update or swap tools.

Stop hitting this again

Pin every script and scheduled task to the PDC by name, or resolve it at runtime with Get-ADDomain. Never let AD pick a random DC for role-sensitive operations. And if you're still running legacy tools that assume a single PDC exists and behaves like Windows Server 2003, it's time to replace them — they're the reason this error code from 2005 is still hanging around today.