0X00002023

ERROR_DS_SIZELIMIT_EXCEEDED (0x2023) on LDAP queries

Windows Errors Intermediate 👁 0 views 📅 May 27, 2026

Happens when an LDAP query returns more results than the server's or client's configured limit. The fix is adjusting the MaxPageSize setting.

You're running a PowerShell script or an LDAP query against Active Directory and it fails with ERROR_DS_SIZELIMIT_EXCEEDED (0x00002023). The error message reads: "The size limit for this request was exceeded." This usually happens when you query a large directory — say, 5000 users or 3000 computers — and the server cuts you off at 1000 results. That's not a bug, it's a default safety limit.

Why this happens

Active Directory enforces a default LDAP page size of 1000 objects per query. That's a server-side limit on the MaxPageSize setting, stored in the LDAP policy. When your query would return more than that, the server returns partial results and this error. The client can also hit its own limit — some LDAP libraries default to 1000 entries — but the server limit is the more common culprit.

The reason this limit exists is to prevent a single oversized query from hogging the domain controller and choking out other requests. But if you're running a legitimate bulk operation — a migration, a compliance audit, a daily sync — you need to raise it.

How to fix it

You have two ways: the quick CLI way using ntdsutil, or the GUI way using ADSI Edit. I prefer the CLI method because it's scriptable and you can undo it just as fast.

Fix 1: Raise MaxPageSize with ntdsutil

  1. Open an elevated Command Prompt on a domain controller.
  2. Run:
    ntdsutil
  3. At the ntdsutil prompt, type:
    ldap policies
  4. Then:
    connections
  5. Connect to the server:
    connect to server localhost

    If you're running this on the DC itself, use localhost. Otherwise specify the DC's FQDN.

  6. Go back:
    quit
  7. Show current policies:
    show values

    Look for MaxPageSize. Default is 1000.

  8. Set it higher — 5000 is reasonable for most environments:
    set MaxPageSize to 5000
  9. Commit the change:
    commit changes
  10. Exit:
    quit
    and then
    quit
    again to leave ntdsutil.

The change takes effect immediately. No reboot needed.

Fix 2: Use ADSI Edit (GUI way)

  1. Open ADSI Edit from Administrative Tools or run adsiedit.msc.
  2. Right-click ADSI Edit in the root and choose Connect to.
  3. In the dialog, change Select a well known Naming Context to Configuration. Click OK.
  4. Navigate to: CN=Directory Service, CN=Windows NT, CN=Services, CN=Configuration, DC=yourdomain, DC=com
  5. Right-click CN=Directory Service and choose Properties.
  6. Find the attribute lDAPAdminLimits. It's a multi-valued string. Look for MaxPageSize=1000.
  7. Edit it to MaxPageSize=5000.
  8. Click OK and close ADSI Edit.

That changes the same underlying policy. ADSI Edit is handy if you're already browsing the configuration partition, but I'd still use ntdsutil for a quick fix.

What if it still fails?

If the error persists after raising MaxPageSize, check these:

  • The client-side limit. If you're using PowerShell's ActiveDirectory module, the -ResultPageSize parameter defaults to 256. That's per-page, not total. But some third-party LDAP clients have their own hard limit. Look for a configuration setting like SizeLimit or MaxResults.
  • Multiple DCs. The LDAP policy is per-DC. If you load-balance queries across multiple domains controllers, you'll need to run the fix on each one. Or better, push it via Group Policy — create a startup script with the ntdsutil commands.
  • The MaxQueryDuration limit. If your query is very complex, it might time out. The default is 120 seconds. You can raise that with the same ntdsutil procedure — set MaxQueryDuration to 300 or whatever makes sense for your data.
  • Replication latency. If you changed the policy on one DC and the client hits another, the policy hasn't replicated yet. Wait a few minutes or force replication with repadmin /syncall.

One more thing: don't set MaxPageSize to 0, which means "unlimited." That's a bad idea in production. A single runaway query can hammer the DC and starve other services. 5000 is plenty for 99% of workloads.

Was this solution helpful?