Fix ERROR_DS_PDC_OPERATION_IN_PROGRESS 0x212A

You're mid-promotion in dcpromo, or you just ran ntdsutil to seize the PDC Emulator role, and Windows slaps you with ERROR_DS_PDC_OPERATION_IN_PROGRESS (0x0000212A). The message reads: "Another operation that requires exclusive access to the PDC FSMO is already in progress." It shows up most often during forest prep, domain prep, or a role seizure when a previous attempt didn't finish cleanly. I've seen it after a zombie dcpromo process, a stuck LDAP write, or a replication cycle that started but never completed.

If you just hit this now, don't reboot yet. Read the next section first — a reboot can make it worse by leaving the FSMO in an inconsistent state.

What's actually happening

Certain Active Directory operations demand exclusive access to the PDC Emulator FSMO. That includes schema updates that touch the PDC, forest/domain prep, and any role transfer or seizure. AD enforces this with a lock stored in the directory itself under CN=Operations,CN=Domain Updates,CN=System,DC=yourdomain,DC=com. When one operation grabs that lock, every other PDC-exclusive request gets the 0x212A error until the first one finishes or times out.

The problem is that lock doesn't always release. If the process that took it crashed, was killed from Task Manager, or lost network connectivity mid-write, the lock stays. Replication can also propagate a stale lock from another DC. That's why you'll sometimes see this error on a DC that isn't even running the operation.

Real trigger I've hit twice: running adprep /forestprep from an RDP session, then losing the session. The prep process dies, the lock stays, and every subsequent attempt throws 0x212A for hours.

The fix

Do these in order. Don't skip steps — each one tells you whether the next is needed.

Check for running AD processes. Open Task Manager or an elevated PowerShell window and look for ntdsutil.exe, dcpromo.exe, adprep.exe, or a stray ldp.exe. Kill anything suspicious, then retry. Many people find a hung adprep from a prior session still holding the lock.
```
Get-Process ntdsutil,dcpromo,adprep,ldp -ErrorAction SilentlyContinue
```
Look up the lock in ADSI Edit. Connect to the Configuration naming context, or better, to the Domain naming context and browse to:
```
CN=Operations,CN=Domain Updates,CN=System,DC=yourdomain,DC=com
```
Inside you'll find child objects. One of them will have an operationInProgress attribute set to a GUID. That GUID points at the operation holding the lock.
Wait out the timeout — or force clear it. Most operations release in 5–15 minutes. If you've waited longer, delete the child object with the operationInProgress attribute still set. Right-click it in ADSI Edit, delete, confirm. This isn't destructive — that object is only a lock marker.

If ADSI Edit won't let you delete it, that means the lock is genuinely held by a live connection. Jump to step 4.
Find the live holder. On the DC holding the PDC Emulator role, open an elevated command prompt and run:
```
repadmin /showconn
repadmin /replsummary
```
Look for a replication partner that's been stuck in IN PROGRESS for more than an hour. If a partner is the culprit, restart the NTDS service on that DC, not on the PDC. Restarting NTDS on the PDC itself is a last resort.
Restart NTDS on the PDC Emulator. Only do this if steps 1–4 didn't clear it. On the PDC, run:
```
net stop ntds /y
net start ntds
```
This forces AD to drop every open operation lock. It causes a brief authentication blip for anyone hitting that DC — so do it during a window, not at 10 AM.
Retry your original operation. Run adprep, dcpromo, or the FSMO transfer again. The error should be gone.

If it still fails

You're likely looking at replication damage, not a stale lock. Check these:

Replication health: run repadmin /showrepl * and look for any failure other than 0. Even one broken partner can keep reintroducing the lock.
Time skew: Kerberos breaks silently past 5 minutes. Run w32tm /monitor on the PDC. If it's more than 5 minutes off from a reliable NTP source, fix that first with w32tm /resync /force.
DNS on the PDC: it should point at itself as primary, and at a partner DC as secondary. If it points only to an external DNS, replication and locks behave badly.
SYSVOL: check dfsrmig /getglobalstate and dfsrmig /getmigrationstate. A stuck SYSVOL migration can hold PDC locks indefinitely.
Event log: filter the Directory Service log on the PDC for event IDs 1083, 1173, and 2089 in the last 24 hours. Those point at which operation is failing to release.

One last thing — if you're doing a seize rather than a transfer, stop. Seize only when the old PDC is permanently dead. A seize on a live DC produces exactly this error half the time, plus a mess you'll be cleaning up next weekend.