Fix ERROR_DS_CONTROL_NOT_FOUND 0x00002042 in AD

When This Error Shows Up

You're running a tool that does LDAP operations — maybe an old VB script, a custom .NET app, or even LDP.exe — and it throws ERROR_DS_CONTROL_NOT_FOUND (0x00002042). The exact message: "The specified control is not supported by the server." This usually happens after you migrate a legacy app to a newer domain controller, or when an admin tries to use an LDAP control like LDAP_SERVER_NOTIFICATION_OID (1.2.840.113556.1.4.528) or LDAP_SORT_OID (1.2.840.113556.1.4.473) against a DC running Server 2019 or 2022.

Root Cause

The culprit here is almost always one of two things: either the domain controller doesn't have the LDAP control registered in its schema, or the LDAP client is requesting a control that was deprecated or removed. Microsoft dropped support for several legacy LDAP controls starting with Windows Server 2016 in some default configurations. Specifically, LDAP_SERVER_NOTIFICATION_OID (for persistent searches) and LDAP_SERVER_SORT_OID (server-side sorting) aren't enabled by default on newer DCs unless you explicitly turn them on via the NTDSA registry key.

Another common cause: third-party LDAP tools that send a control OID not in the DC's supportedControl attribute. AD checks the supportedControl attribute on the rootDSE. If your control isn't listed, the error pops.

Step-by-Step Fix

Identify the control OID from the client. Look at the tool's logs or Wireshark capture. Common OIDs: 1.2.840.113556.1.4.528 (notification), 1.2.840.113556.1.4.473 (sort), 1.2.840.113556.1.4.474 (sort response).
Check if the DC supports it. On a DC, run:
```
ldp.exe
```
Connect to port 389 (or 636 for LDAPS). Browse to rootDSE, view the supportedControl attribute. If your OID isn't there, that's your confirmation.
Enable the control via registry. If the control is missing and you need it (e.g., persistent search for Exchange or a backup tool), add this reg key on every domain controller:
```
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
"LDAPServerNotificationOID"=dword:00000001
"LDAPSortOID"=dword:00000001
"LDAPVLVOID"=dword:00000001
```
Restart the NTDS service after. Use net stop ntds then net start ntds.
Update the client application. If you can, modify the LDAP client to use a supported alternative. For example, instead of persistent search, use the DirSync control (1.2.840.113556.1.4.841) which is supported on all modern DCs.
Verify after fix. Re-run ldp.exe or your tool. The OID should now show in supportedControl.

What to Check If It Still Fails

Firewall or load balancer stripping LDAP controls. Some load balancers can modify LDAP packets. Bypass it temporarily and test.
Application pool identity on the client machine — does the account have Read access to the rootDSE? Use dsquery * -scope base -attr * to test.
Schema version mismatch between DCs. Run dcdiag /test:ldapbind. If schema is out of date, run repadmin /syncall.
Third-party LDAP proxy (like Azure AD Connect or a firewall LDAP gateway) intercepting the request. Check if the proxy supports the control.

Don't bother with a full AD rebuild — that rarely helps here. The issue is almost always a missing registry tweak or an outdated client. If you're stuck, post the exact control OID and your DC version — that narrows it down fast.