Fix 0X00002045: LDAP sort control missing in AD

Quick answer

Install KB article 975933 on the domain controller (Windows Server 2008 R2 or earlier) or make sure the LDAP client sends the request to a global catalog server that supports LDAP_SERVER_SORT_OID.

What's actually happening here

The error 0X00002045 with message ERROR_DS_CONTROL_MISSING means the LDAP server received a search request with the sort control (OID 1.2.840.113556.1.4.473) but it doesn't have that control registered. This isn't a network failure or a credential problem. The server literally tells you: "I can't sort results because I don't have the code to handle that control."

This typically shows up in two scenarios:

You're running LDP.exe or a custom LDAP client that requests sorted results.
An older application (like Exchange 2003 or some third-party backup tools) tries to use the sort control, and the DC is Windows Server 2008 or 2008 R2 without the relevant update.

The root cause: Microsoft removed the sort control from some domain controllers starting with Windows Server 2008 to reduce the attack surface. They shipped it as an optional component. If you don't install it, the control doesn't exist. No negotiation — the server just says "I don't have it."

Step-by-step fix

Identify the DC where the error happens. Look at the event logs or the LDAP client's debug output. The error comes from the server, not the client. You need to fix the DC that's refusing the sort control.

Check current sort control support. Run this on the DC:

ldifde -f test.ldf -s localhost -d "dc=domain,dc=com" -r "(objectClass=*)" -l "cn" -b "DOMAIN\Admin" password

If it fails with 0X00002045, the control is missing.

Install the sort control update (Windows Server 2008 R2 and earlier). Download and install KB975933. This adds the LDAP_SERVER_SORT_OID registration. After install, reboot the DC.
For Windows Server 2012 and later, the sort control is included by default. If you still see the error, it means the LDAP client is sending the request to a DC that doesn't have the control loaded (maybe a read-only DC or a misconfigured global catalog). Check the DC's role:
```
Get-ADDomainController -Filter * | Select-Object Name, Site, IsGlobalCatalog
```
If the server isn't a GC, move the query to one that is, or enable the GC flag.
Test with LDP.exe. Open LDP, connect to the DC, go to Options > Controls. For the sort control, enter 1.2.840.113556.1.4.473 with the critical flag checked. If it still fails after the fix, the control isn't loaded. Repeat step 3.

Alternative fixes if the main one doesn't work

Remove the sort request from the client. If you can't patch the DC (e.g., it's an old production server you can't reboot), modify the LDAP client to not request sorting. For example, in PowerShell, use -SearchScope Subtree without sorting, then sort locally in memory:
```
$results = Get-ADUser -Filter * -Properties Name | Sort-Object Name
```
Point to a different DC. If at least one DC has the control installed, redirect the LDAP client to that specific server instead of using DNS round-robin. Set the server name in the connection string.

Manual registration (last resort). You can try adding the sort control via the registry:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
"LDAP Controls"=hex(7):31,00,2e,00,32,00,2e,00,38,00,34,00,30,00,2e,00,31,00,31,00,33,00,35,00,35,00,36,00,2e,00,31,00,2e,00,34,00,2e,00,34,00,37,00,33,00,00,00,00,00

But this is fragile — a Windows update might overwrite it. Use KB975933 instead.

Prevention tip

Don't rely on server-side sorting for production applications. It's a convenience, not a guarantee. If your app fails hard when sorting isn't available, build a fallback that sorts results client-side. This way, no matter which DC answers, you won't hit 0X00002045. Also, keep your DCs on the same patch level — mix-and-match patch status across DCs causes these kinds of inconsistencies.