Fix ERROR_DS_OUT_OF_VERSION_STORE (0X0000217D) Fast

Quick answer: Restart the NTDS service or increase the version store via registry. If that fails, tombstone cleanup or a database restore might be needed.

This error—0X0000217D—shows up when Active Directory (or AD LDS) runs out of space to track object changes. Every directory update creates a version of the object, and Windows keeps these old versions for replication partners that haven't caught up yet. Think of it as a backlog: if your domain controller processes more writes than it can replicate out, the store fills up, and boom—new writes get blocked. I've seen this hit hardest on busy global catalog servers or DCs handling loads of group membership changes. The error usually pops in the Directory Service log with Event ID 0X0000217D, and AD stops accepting updates until you clear the bottleneck.

The Steps

1. Stop the Bleeding

Open an elevated Command Prompt.
Type net stop ntds and hit Enter. Wait for AD to stop—this can take a minute.
Then net start ntds. This clears the version store temporarily.

If AD won't stop gracefully, use net stop ntds /force. Yes, it's forceful, but this error hard-locks the database anyway.

2. Increase the Version Store

The real fix is giving AD more room. For Windows Server 2012 R2 and later, the default store is 100 MB per CPU core. You can bump it to 200 MB or higher.

Open Regedit.
Go to HKLM\System\CurrentControlSet\Services\NTDS\Parameters.
Find EDB Max Version Store. If it's not there, create a DWORD (32-bit) with that name.
Set its value in megabytes. Start with 200 (decimal). For busy DCs with 8+ cores, I've used 500. Don't go above 1000—it eats memory.
Restart the NTDS service (net stop ntds && net start ntds).

3. Check Replication Health

A full version store often means a replication partner is behind. Run repadmin /syncall /AdeP on the affected DC. Look for ERROR_DS_OUT_OF_VERSION_STORE in the output—that tells you which partner can't keep up. If you find a stale DC, force a sync with repadmin /sync <DC> <naming context> /force.

If the Main Fix Doesn't Work

Alternative 1: Restart the DC

Sometimes the service restart fails or the error comes back immediately. A full server reboot flushes the store clean. I've had situations where a reboot bought me a few days to plan a real fix. It's temporary but gets users working.

Alternative 2: Force Tombstone Cleanup

If the store keeps filling, you've likely got too many tombstones (deleted objects). Check with repadmin /showrepl for orphaned objects. Then run repadmin /removelingeringobjects <DC> <naming context> /advisory_mode to identify them, then without /advisory_mode to delete. This one's risky—back up the database first.

Alternative 3: Restore from Backup

Last resort: if the version store corruption is deep—like the database itself is fragmented—you'll need a system state restore to a backup before the error hit. Yes, it's downtime, but rebuilding a DC from scratch takes longer.

Prevention Tips

Monitor replication. Use repadmin /replsummary daily on your PDC emulator. A consistently high backlog is a red flag.
Don't oversize the store. I've seen admins set it to 2000 MB thinking more is better—it just wastes RAM. Stick to 100–500 MB based on your write load.
Keep your DCs on the same OS. Mixed 2012 R2 with 2016 or 2019 can cause version store mismatches during replication. Not always the cause, but it's a common one.
Reduce group membership churn. If a script updates groups every 5 minutes, rewrite it to batch changes. Each write eats a version store slot.

This error is a pain, but once you tame the replication backlog, it usually stays quiet. If it doesn't, check for third-party LDAP apps hammering writes—they're often the hidden cause.