0X000020DF

Fix ERROR_DS_SCHEMA_ALLOC_FAILED 0x000020DF on Windows Server

EP
Erropedia Team
📅 September 20, 2026 📅 Updated Sep 24, 2026 👁 10 views Windows Errors Advanced
Active Directory can't extend the schema because the Schema Master can't allocate memory or write to disk. Here's the real fix, in order.

You ran adprep /forestprep to prep the forest for a newer Windows Server, and instead of a clean success you got ERROR_DS_SCHEMA_ALLOC_FAILED (0x000020DF). That specific hex — 0x20DF — isn't a generic "something went wrong" code. It's LDAP telling you the Schema Master tried to allocate memory for the schema update and failed. So the fix is about giving that DC enough room to breathe.

Fix it now

Stop the schema operation, free resources on the Schema Master, then retry. Do them in this order.

1. Find the Schema Master

netdom query fsmo

Write down which DC holds the Schema Master role. Everything below happens on that machine, not on the DC where you ran adprep.

2. Check free disk space on C: and the NTDS volume

Get-PSDrive -PSProvider FileSystem | Select Name, Used, Free
dir C:\Windows\NTDS

If the drive hosting NTDS.dit has under 15% free, that alone can trigger 0x20DF. The schema extend writes a large transaction to edb.log before touching the database, and ESE refuses if the log volume can't grow. Clear space, or move NTDS.dit and the logs to a bigger volume with ntdsutil.

3. Check memory pressure

Get-Counter '\Memory\Available MBytes' -SampleInterval 1 -MaxSamples 5
tasklist /svc | findstr lsass

If available memory sits under 500 MB, the LDAP allocator can't hand the schema engine the block it needs. Reboot the DC or move some roles off it. On a DC with 4 GB RAM and a print spooler plus WSUS plus Exchange management tools installed, this happens more often than people admit.

4. Verify no other schema operations are running

Two admins extending the schema at once, or a half-finished adprep from yesterday, will lock the schema partition. Check the Directory Service log:

Get-WinEvent -LogName 'Directory Service' -MaxEvents 50 | Where-Object {$_.Id -in 1479,1480,1539,1963} | Format-List TimeCreated, Id, Message

If there's a stale 1479 (schema update in progress), wait it out or restart NTDS:

net stop ntds
net start ntds

Restarting NTDS rolls back any half-applied schema transaction. It's safe. It's also the fastest way to clear a stuck lock.

5. Retry adprep from the Schema Master itself

Don't run it over the network from a management box. Log on to the Schema Master and run:

adprep /forestprep
adprep /domainprep /gpprep

You'll be prompted to confirm the schema version change. Say yes.

6. If it still fails, raise the LSA memory allocation

On very large forests — think 40,000+ users, deep OU trees, dozens of extended attributes — the default LSA heap is too small for the schema diff. Add these to the registry on the Schema Master, then reboot:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"LsaDbExtPt"=dword:00000001
"LsaMemoryThreshold"=dword:00001000

Reboot, retry adprep. The threshold value is in KB and 0x1000 (4096) is a safe starting point. Don't go wild — 32768 or higher can hide a genuine memory leak.

Why this actually works

What's happening under the hood: when you extend the schema, the LDAP server on the Schema Master has to allocate a contiguous memory block large enough to hold the entire updated schemaNamingContext plus the incoming attribute definitions. NTDS then writes a single ESE transaction wrapping every change. If either the allocator fails (memory) or ESE can't extend the log (disk), LDAP maps the failure back to ERROR_DS_SCHEMA_ALLOC_FAILED. The name is slightly misleading — it's not that AD ran out of schema space, it's that the schema operation couldn't allocate the resources it needed to run.

The reason step 3 (memory) and step 2 (disk) come before the retry is that the schema extend is atomic. It fails the whole operation if any piece can't be satisfied, so fixing only one of the two won't get you past 0x20DF. People chase the disk fix, reboot, retry, and get the same error because lsass is still starved. Fix both, then retry.

If you see 0x20DF in the Directory Service event log alongside Event ID 1539 (Internal processing error), that's the smoking gun for the memory allocation path. Event 1479 alone means a lock, not a resource shortage.

Less common variations

0x20DF on a single-DC forest after a non-authoritative restore

A restored DC can come back with a schema cache that doesn't match NTDS.dit. The fix is a full reboot of the DC, not a service restart, because the schema cache lives in the LSA process. If a reboot doesn't clear it, run repadmin /syncall /AdeP from another DC — yes, from a replica, because the Schema Master's own view can be the broken one.

0x20DF when installing Exchange Server

Exchange setup calls adprep internally and escalates the error as "The schema master does not have permissions to update the schema." That message is wrong for this error. The real cause is almost always that the Schema Master is a 2012 R2 DC with 2 GB RAM and no page file headroom. Give it 8 GB and a 16 GB page file, then run Setup /PrepareSchema again.

0x20DF after applying a Windows cumulative update

Some CUs (KB5019966, KB5023706 for Server 2022) have triggered this when the DC also runs Defender with real-time scanning enabled. The AV driver grabs a chunk of non-paged pool during the schema transaction and the allocator can't find a large enough contiguous block. Add NTDS.dit, edb.log, and C:\Windows\NTDS to Defender exclusions and retry. This is documented in Microsoft's AD AV exclusion guidance, but nobody reads it until they hit 0x20DF.

0x20DF on a DC that's also a file or SQL server

Don't do that. Seriously. A DC hosting SQL will starve NTDS exactly when the database hits a checkpoint, and schema operations are the first casualty. If you can't remove the role, at least cap SQL's max server memory to leave 4 GB headroom for the OS and AD.

Prevention

  • Keep the Schema Master on a DC with at least 8 GB RAM and 15% free disk on every volume hosting NTDS or the ESE logs.
  • Exclude NTDS.dit, edb.log, edbres*.jrs, and C:\Windows\NTDS from all AV real-time scanning on every DC.
  • Run adprep /forestprep during a maintenance window, with no other schema operation in progress, and with the Schema Master freshly rebooted.
  • Monitor Event ID 1539 and 1479 — a spike in either is a two-week warning before 0x20DF shows up.
  • Don't install Exchange, SQL, WSUS, or the print spooler role on the Schema Master. It's a role holder, not a workload server.

If you've done all of that and 0x20DF still bites during a schema extend, check dcdiag /test:checksecurityerror and repadmin /showrepl on the Schema Master. A broken replication link to a single authoritative replica will make the Schema Master think it can't complete the transaction, and it maps that back to the same error code. Schema operations are a forest-wide act, even though they execute on one DC.

Related Errors in Windows Errors
0XC0000024 STATUS_OBJECT_TYPE_MISMATCH (0xC0000024) – Real Fixes That Work 0XC0262112 Fix ERROR_GRAPHICS_ALLOCATION_CLOSED 0xC0262112 in 5 Steps 0X000000CB Fix ERROR_ENVVAR_NOT_FOUND (0x000000CB) in Windows 0XC00000E8 STATUS_INVALID_USER_BUFFER (0xC00000E8): Real Fixes for Small Biz PCs
ERROR_DS_SCHEMA_ALLOC_FAILED 0x000020DF schema allocation failed Active Directory schema master adprep forestprep error DC memory exhaustion NTDS database disk space schema master role transfer Windows Server 2019 domain controller Windows Server 2022 DC LSA memory limit NTDS.dit disk full dcdiag schema test adprep /forestprep 0x20DF Active Directory extend schema error

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.