Fix ERROR_DS_NON_ASQ_SEARCH 0X000021B0 in Active Directory

Happens when you query Active Directory with attribute scoped query on a non-ASQ attribute. The fix is to use only ASQ-supported attributes or change your search filter.

When This Error Shows Up

You're running a script or tool that queries Active Directory — maybe PowerShell Get-ADUser with a custom LDAP filter, or an older VB script. You get back ERROR_DS_NON_ASQ_SEARCH (0X000021B0). The message says: "The requested search operation is not supported for attribute scoped query (ASQ) searches."

This usually happens when you try to use an attribute scoped query (ASQ) on a normal attribute that isn't designed for ASQ. For example, you try to do a one-level search on memberOf or manager using ASQ syntax, but those attributes don't support it. The error triggers about 9 times out of 10 when someone copies a sample LDAP filter from the internet and pastes it into a script without checking if the attribute is ASQ-compatible.

Root Cause in Plain English

Attribute scoped query is a special feature in Active Directory. It let's you search inside a linked attribute — like member on a group — and return results from that group's members. It works only on attributes that are linked (have a back link). Examples: member, managedBy, manager (the forward link), and some exchange attributes.

But for ASQ to work, you must use the right syntax. You can't just throw it on any attribute. The system sees you're trying an ASQ on an attribute that either isn't linked, or you're using the wrong LDAP control. The error code 0X000021B0 is AD's way of saying: "That operation doesn't make sense here."

The Fix — Step by Step

Check the attribute you're querying.
Open ADSI Edit or LDP.exe (installed with RSAT tools). Right-click the domain, choose "Connect to" with default naming context. Browse to an object that has the attribute you're using. Double-click it, find the attribute name. If it's not a linked attribute (check the linkID in schema), ASQ won't work.
Remove the ASQ LDAP control from your query.
If you're using PowerShell with -LDAPFilter, drop any (attr:1.2.840.113556.1.4.1799:=value) syntax. That's the ASQ control. Replace it with a normal filter like (attr=value).
Use the correct LDAP filter syntax for non-ASQ attributes.
For example, instead of:
```
(memberOf:1.2.840.113556.1.4.1799:=CN=Group,DC=domain,DC=com)
```
Use:
```
(memberOf=CN=Group,DC=domain,DC=com)
```
This is a simple group membership search that works on any DC.
If you must use ASQ, pick a compatible attribute.
The safest ASQ attributes are member and managedBy. For example, to search all members of a group:
```
(member:1.2.840.113556.1.4.1799:=CN=Group,DC=domain,DC=com)
```
That returns the DN of each member. Don't try it on description or displayName.
Check your script or tool version.
Old PowerShell modules (like the ActiveDirectory module from Windows 7/2008 R2) sometimes mis-handle ASQ. Update to the latest RSAT for your OS. For Windows 10/11, install the latest Windows update, then re-add RSAT tools.
Test with a simple command first.
Open PowerShell as admin. Run:
```
Get-ADGroupMember -Identity "Domain Admins"
```
If that works, ASQ isn't needed. The error is in your custom filter.

What to Check If It Still Fails

If you've done the steps above and the error keeps popping up, check these:

You're using the right LDAP control OID. The ASQ OID is 1.2.840.113556.1.4.1799. Some old scripts use 1.2.840.113556.1.4.1798 which is something else — that will fail.
The attribute you're targeting is not forward-linked. For example, manager is a forward link. But directReports is the back link. You can only ASQ on the forward link (manager). Check the schema with Get-ADObject -SearchBase "CN=Schema,CN=Configuration,DC=domain,DC=com" -Filter {cn -eq "manager"} and look for linkID.
Your search base is wrong. ASQ requires the search base to be the Distinguished Name (DN) of an object that has the attribute. If you set the base to a container like OU=Users,DC=domain,DC=com instead of CN=TargetGroup,OU=Groups,DC=domain,DC=com, the query won't find the attribute and throws this error.
Third-party antivirus or security software is blocking LDAP controls. Temporarily disable it for a test. If the error goes away, add an exception for LDAP queries from your script.

One last tip: If you're managing Exchange, the msExch* attributes often support ASQ, but you need the Exchange schema extensions loaded. Run Get-ADObject -SearchBase "CN=Schema,CN=Configuration,..." -Filter {name -like "msExch*"} | Select -First 5 to confirm they exist. If not, the error is because the attribute isn't in the schema at all.