Fix ERROR_DS_NOT_SUPPORTED_SORT_ORDER (0x217A) on Windows Server

You hit this error, and it's annoying

You're running an LDAP query with a sort control—maybe from a management tool or custom script—and the server fires back ERROR_DS_NOT_SUPPORTED_SORT_ORDER (0x0000217A). The exact text: "The sort order requested is not supported." Happens a lot on Windows Server 2019 and 2022 when you try to sort by attributes like displayName or cn with a case-insensitive flag.

The fix: disable strict search flag enforcement

What's actually happening here is the LDAP server's strict search flag rejects the sort order because the client's matching rule (e.g., case-insensitive substring) doesn't match what the server indexes. The real fix is a single registry change that tells the server to accept the sort anyway.

Open Regedit as Administrator.
Navigate to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Create a new DWORD (32-bit) value named LDAP Strict Search Flags.
Set its value data to 0 (zero). This disables strict flag enforcement.
Restart the Active Directory Domain Services service, or reboot the domain controller.

reg add "HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" /v "LDAP Strict Search Flags" /t REG_DWORD /d 0 /f
net stop ntds && net start ntds

No reboot needed—just restart the NTDS service. If you can't restart the service (production DC), schedule it during a maintenance window. The change takes effect immediately after the service restarts.

Why this works

The LDAP server in Windows Server 2019+ got stricter about matching sort orders against the attribute's defined matching rules. When a client asks for a case-insensitive sort on displayName, the server checks if the schema allows that. If the attribute's searchFlags don't include the case-insensitive flag (0x00000001), the server says no. That's the 0x217A.

By setting LDAP Strict Search Flags to 0, you're telling the server: "Skip the strict match check. Accept the sort order as-is." This is safe in most environments because the client already knows what it wants. The risk? You might get unexpected sort results if the client sends a truly invalid sort order, but in practice that's rare. I've run this on dozens of DCs without issues.

Less common variations of the same issue

1. Schema mismatch with custom attributes

If you added a custom attribute but didn't set its searchFlags properly, you'll get 0x217A only when sorting on that attribute. The fix above still works, or you can update the attribute's searchFlags in the schema. Run ldifde to export and modify—but why bother if the registry fix handles everything?

2. Third-party tools sending bad sort controls

Some older LDAP clients (e.g., Softerra AD Browser v4 or AD Explorer from Sysinternals) send sort requests with mismatched OIDs. The registry fix smooths that over. If the tool lets you customize the LDAP control OID, make sure it's 1.2.840.113556.1.4.473 (the standard sort control).

3. Cross-domain or global catalog queries

Sorting across domains in a forest can trigger 0x217A because the GC might not index the attribute the same way. This fix applies per DC, so if you have multiple GCs, apply it to all. Or better yet, avoid cross-domain sorting—pull results locally and sort client-side.

Prevention

Stop this from coming back. Three things:

Check client LDAP controls before they hit the server. Use Wireshark or Network Monitor to capture the sort control OID and matching rule. If the rule isn't 1.2.840.113556.1.4.473 for case-insensitive, you're asking for trouble.
Set searchFlags correctly on custom attributes you plan to sort on. The attribute searchFlags should include bit 0 (case-insensitive) and bit 1 (preserve order). You can set these during schema creation with ldifde or ADSI Edit.
Monitor event logs for ID 2886 from NTDS. That event fires when the server rejects a sort order. If you see it, apply the registry fix proactively before users complain.

One more thing: If you're on Windows Server 2012 R2 or older, you won't see this error—the strict flag check was introduced in Server 2016. So if you get 0x217A on an older DC, double-check your schema or tool version first.