Fix ERROR_DS_TIMELIMIT_EXCEEDED (0X00002022) in 5 Steps

30-Second Fix: Check Your Query Scope

First thing I ask every client: "Are you searching the whole domain?" Most of the time, someone's running a broad LDAP query against the root of the directory without any filter. That'll hit the time limit fast, especially with 10,000+ objects.

Quick test: Run your query with a specific base DN. Instead of LDAP://DC=yourdomain,DC=com, try LDAP://OU=Users,DC=yourdomain,DC=com. If it works now, your problem is scope.

Had a client last month whose entire print queue died because a monitoring tool was doing an unbounded (objectClass=*) search against the forest root. Narrowed it to one OU and it snappe back.

If that's not the issue, move on.

5-Minute Fix: Increase Server Time Limit

The default time limit on a domain controller is 120 seconds for LDAP searches. That's fine for small shops, but if you're hitting 0X00002022, either you've got a slow link or a huge directory. Either way, bumping the limit buys you time.

Via Group Policy:

Open Group Policy Management Console.
Create or edit a GPO linked to the domain controllers OU.
Go to Computer Configuration -> Policies -> Administrative Templates -> System -> LDAP Client.
Enable LDAP Timeout and set it to 180 or 300 seconds.
Run gpupdate /force on your DCs.

Via registry (if you prefer direct):

HKLM\SYSTEM\CurrentControlSet\Services\LDAP\Parameters
LDAPSessionTimeout = DWORD: 180

I've seen this fix work for 80% of cases. But sometimes the client's just hitting a real data wall.

15+ Minute Fix: Use Paged Results or Index Attributes

If you're still stuck, the issue is likely an LDAP query that returns thousands of objects without paging. Active Directory supports paged results (RFC 2696), but not all apps do. Check your application's configuration.

Enable paging in PowerShell:

$search = New-Object DirectorySearcher([ADSI]"LDAP://DC=yourdomain,DC=com")
$search.PageSize = 1000
$search.FindAll()

If your app doesn't support paging, you need to add indexes for the attributes you're filtering on. For example, if you query (sn=Smith) and sn isn't indexed, the DC scans the whole directory.

Check existing indexes: Open ADSI Edit, right-click the partition, choose Properties, look at searchFlags on each attribute. If sn has bit 1 set, it's indexed.

Add an index via PowerShell:

Import-Module ActiveDirectory
Set-ADObject -Identity "CN=Sn,CN=Schema,CN=Configuration,DC=yourdomain,DC=com" -Replace @{searchFlags=1}

That's a schema change, so test in a lab first.

Real story: Last year, a law firm's HR app kept timing out because it searched the whole domain for every employee record. The devs wouldn't fix the code. I indexed the employeeID attribute and cut search time from 90 seconds to 2. Client was happy, devs still grumpy.

If all else fails, check network latency between the client and the DC. A ping over 50ms can cause timeouts with large result sets. Move the app closer to the DC or use site-aware DC selection.

That's it. Start with the scope, then the timeout, then indexing. You'll get it fixed.