Fix ERROR_DS_NO_RESULTS_RETURNED 0X00002041 in AD

Quick answer for pros

Check your LDAP base DN and port. The error means the server processed your query but found nothing to return. Either you pointed at the wrong naming context, or you hit a Global Catalog port (3268) expecting a default partition (389). Fix the base DN or switch to port 389.

Why this happens

I've seen this error trip up admins for years. It's not a server crash or a permissions failure. The directory service actually ran your LDAP query end-to-end and came back with zero matching objects. That's the "no results" part. The error code 0X00002041 is the DSID equivalent of a clean empty result set — but your application or script treats it as a failure.

The usual culprit is a misconfigured base DN. You're searching in CN=Users,DC=contoso,DC=com but the actual users live in an OU like OU=Employees,DC=contoso,DC=com. Another classic: you're connecting to port 3268 (Global Catalog) but using a base DN that only exists on port 389, or vice versa. Global Catalog only holds a partial replica of the forest, so some objects won't be found unless you query the right partition.

I've also hit this when a script dynamically builds the base DN from a user's distinguishedName and the variable comes back empty. A null base DN often results in this error, not a syntax error.

Fix it in numbered steps

Verify your base DN. Open ADSI Edit (adsiedit.msc), connect to the domain or schema partition, and confirm the exact path of the OU or container you need. Copy the distinguishedName from the object's properties. Don't guess — typos here are the #1 cause.
Check the port. If you're using LDAP://server:3268, that's the Global Catalog. For a domain-specific query, use LDAP://server:389. Swap the port and retest. If you need GC data, make sure your base DN is the forest root, like DC=contoso,DC=com, not a child domain.
Test with a simple tool. Use PowerShell one-liner to see what's actually returned:
```
Get-ADUser -Filter * -SearchBase "OU=Employees,DC=contoso,DC=com" -Server dc01.contoso.com
```
If that returns nothing, the base DN is wrong. If it errors, you have a connectivity or auth problem.
Check for referral chasing. Some LDAP clients (especially in .NET) don't follow referrals by default. If you query a child domain with a forest-wide base DN, you'll get zero results unless you set ReferralChasing = All. In PowerShell, that's automatic, but in raw LDAP, add the control.
Look for tombstoned or orphaned objects. Rare, but if you query a specific object by GUID and it's been deleted (tombstoned), you'll get this error. Use ntdsutil to check the tombstone lifetime.

Alternative fixes if the main ones fail

If you've verified the base DN and port and still get 0X00002041, try these:

Run the query from a different machine. Maybe the DC you're hitting is a read-only domain controller (RODC) with a filtered attribute set. That can hide objects from your search.
Temporarily disable the Global Catalog on one DC and re-enable it. I've seen stale GC partitions cause phantom empty results. Replication delay is a real thing.
Use repadmin /showrepl to confirm the domain partition is fully replicated. If a DC hasn't received the newest objects, your query finds nothing. This bites more often than you'd think.
Examine your LDAP filter. A filter like (&(objectClass=user)(memberOf=CN=Group,OU=Groups,DC=contoso,DC=com)) can break if the group's DN is wrong. The filter evaluates to false for all objects, so you get an empty set — exactly this error.

Prevention tip

The easiest way to avoid this error is to add a simple null-check in your scripts after the query. If the result set is empty, log the base DN and filter before claiming failure. Nine times out of ten, that log line shows you exactly what's wrong. Also, standardize your base DN strings in a config file, not hardcoded in each script. I've stopped counting how many hours I've spent hunting a bad DN that was copy-pasted into fifteen different tools.

One more thing: if you're using ADO in VBScript or classic ASP, remember the dsquery style, but with ADO, the ADsPath is the base. Get that wrong, and you'll see 0X00002041 every time. Use the LDAP:// provider string exactly.