Fix ERROR_DS_DRA_OUT_OF_MEM (0X000020FE) in AD Replication

Active Directory replication fails with out-of-memory error. This fix clears the replication queue and adjusts the LSA memory limit. I explain the real cause and prevention steps.

You're staring at 0X000020FE and it's not going away on its own

I've seen this error on domain controllers that have been running for months without a reboot, especially after a big patch Tuesday or when you've added a bunch of new users. The replication process just chokes because it can't grab enough memory to build the update packet. Let's get it fixed.

The immediate fix: clear the replication queue and bump the LSA limit

Open an elevated PowerShell or CMD on the destination domain controller (the one throwing the error). First, force a replication attempt to see if it's a transient issue:

repadmin /syncall /AdeP

If that still fails with 0X000020FE, you need to clear the replication queue. This is safe for most environments, but do it during a maintenance window:

repadmin /queue /clear

Now, the memory limit. The Local Security Authority (LSA) process has a default paged pool limit that's too low for large replication payloads. You'll raise it via registry:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LsaPagedPoolSize /t REG_DWORD /d 0x20000000 /f

That sets it to 512 MB. Reboot the DC for the change to take effect, then run repadmin /replsum to confirm replication is healthy.

Why this works

Here's what's actually happening: when a domain controller initiates a replication, it packages up all the changes since the last successful sync into a single update. If that package is huge—say, you've had a bulk import or a deleted container with thousands of objects—the DRA (Directory Replication Agent) needs to allocate a contiguous block of memory. The LSA process, which hosts the DRA, is limited by the LsaPagedPoolSize value. Default is 32 MB on older OSes, and even on Server 2019 it's often too small for a big replication.

Clearing the queue does two things: it drops any stuck replication attempts that may be holding memory, and it forces the next replication to start fresh. That's why the order matters—clear the queue first, then raise the limit. If you raise the limit without clearing, the stuck request might still be there and continue to fail.

A note on the reboot

Yes, you need to reboot. The LSA reads that registry value at boot time. There's no way around it unless you want to restart the LSA process, which is effectively a reboot anyway (it'll crash the DC). So schedule it.

When this isn't the problem

Sometimes 0X000020FE is a symptom of something else. Here are the variations I've run into:

Disk space is critically low on the DC. The DRA spills to the database file (NTDS.DIT) and if the pagefile or the database drive is full, memory allocation fails. Check with fsutil volume diskfree C:. If it's under 10%, free up space first.
An oversized attribute. If you've got a custom schema attribute holding a massive blob (like a binary photo or a multi-valued attribute with thousands of entries), the replication packet exceeds the LSA's max even with the raised limit. You'll see this in the event log as a size warning alongside the error. The fix is to clean up that attribute or move it to a separate partition.
Memory pressure on the host. If the DC is a VM and the host is running with overcommit, the guest might not actually get the memory it requests. Check the guest's actual allocation with Get-Counter '\'\Memory\Available MBytes'. If it's below 2 GB, bump the VM's RAM. The registry tweak won't help if the guest has no physical memory to back it.

Also, don't waste time on the LsaMaximumMemory value. I've seen people set that, but it doesn't apply the same way on modern Windows. Stick with LsaPagedPoolSize.

Preventing this from happening again

The real fix is to stop creating replication packets that blow past the memory limit. A few habits help:

Do bulk user imports in chunks of a few hundred, not thousands at once. Script it to run in batches.
Monitor the replication queue length. If it's consistently above 50, something's stuck. Use repadmin /queue /statistics to track trends.
Set the LSA paged pool size higher from the start on all DCs. I set 512 MB on every DC in my environment and haven't seen this error since.
Keep the AD database and logs on separate drives, and keep at least 20% free on both. The DRA uses the log drive for temporary spill.

If you're on Server 2016 or older, consider a planned upgrade—later builds handle memory allocation more gracefully, but the registry fix will still get you out of a jam today.