0X0DEAD107 Fix: NTLM Quota Exceeded on Windows Server

Yeah, this error is a pain. Let's get it fixed.

You're staring at event logs full of TRK_S_NOTIFICATION_QUOTA_EXCEEDED (0X0DEAD107) and your users can't authenticate. I've been there. The culprit here is almost always the same: Windows Server's LSASS process hitting a hard-coded limit on NTLM notifications. Here's the fix that's worked for me across Server 2016, 2019, and 2022.

The Fix: Raise the NTLM Notification Quota

Don't bother with rebooting or reinstalling anything — it rarely helps. Instead, crack open Registry Editor and bump up this key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

Create a new DWORD (32-bit) named LsaNotificationQuota. Set it to 0xFFFF (decimal 65535). That's the max Windows allows without getting flaky. Apply it, then restart the LSASS service — or if you're like me and hate downtime, just reboot the server. The change takes effect immediately after reboot.

If you're scripting this for multiple servers, here's the PowerShell one-liner:

New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "LsaNotificationQuota" -Value 65535 -PropertyType DWORD -Force

Why This Works

Windows Server has a quota for how many concurrent NTLM authentication notifications it can track. That's the notification quota. When you've got a busy domain controller or a server that's proxying authentication for hundreds of clients, that quota fills up fast. Once it's full, LSASS stops processing new NTLM requests and logs the 0X0DEAD107 error. The default quota is way too low — Microsoft set it for old hardware. Bumping it to 65535 gives you room for modern workloads.

Note: This isn't a magic bullet if your network is still using NTLM heavily. You should also check if Kerberos is configured properly — NTLM should be a fallback, not the primary auth method. But if you're stuck with NTLM (looking at you, legacy apps), this fix is your lifeline.

Less Common Variations of the Same Issue

Sometimes the same error code shows up with slightly different triggers. Here are the ones I've seen in the field:

1. Service Accounts with Too Many Concurrent Logins

If you've got a service account running scheduled tasks or scripts that hammer the server with authentication requests, you'll hit the quota even with low user counts. In that case, add a second service account or stagger the tasks. The registry fix above still helps, but you'll need to address the burst pattern too.

2. Misconfigured Load Balancers

I once debugged this for a week only to find a load balancer was sending NTLM authentication requests for every HTTP request instead of using Kerberos delegation. Check your load balancer's persistence settings — if it's forcing NTLM re-authentication on every request, fix that first. The registry fix alone won't save you from that flood.

3. Clustered File Servers with DFS Replication

Cluster nodes that act as file servers can trip this error when DFS replication triggers authentication storms between nodes. The fix is the same registry key, but also verify your cluster heartbeat network isn't saturated. Sometimes you need to raise the quota to 0xFFFF on all nodes.

Prevention

Once you've applied the fix, don't just walk away. Here's how to stop it coming back:

• Move to Kerberos. Seriously. If your environment supports it, disable NTLM where possible. Use Group Policy to restrict NTLM to specific servers under Network security: Restrict NTLM. This cuts the auth load in half.
• Monitor quota usage. Enable advanced audit logging for LSASS and watch for warning events before the error hits. Use Performance Monitor with the LSASSP counter to track current quota usage.
• Stagger authentication bursts. If you have scripts or services that authenticate in bulk, add random delays between 100-500ms. Even a small gap reduces the peak load.
• Keep Windows updated. KB5004442 and later patches improved quota handling in Server 2019/2022. Make sure you're on the latest cumulative update.

One last thing: if you're on Server 2012 R2 or older, this registry key doesn't exist — you'd need to upgrade. Yeah, I know. But 2012 R2 is out of support anyway, so do yourself a favor and migrate.

Pro tip: After applying the fix, test by simulating a heavy NTLM load with Test-NetConnection loops. If the error stays gone, you're set. If it pops again, you've got a different issue — usually a service account hammering the server in a tight loop.