ADSI conflict error 0X0000217E fix
This Active Directory error means you used two controls that can't work together. Fix it by checking your LDAP filter or script and removing one control.
Quick answer: Strip your LDAP query down to one server-side control per operation. Remove any extra paging, sort, or search controls that fight each other.
I got this call from a small law firm last Tuesday. Their HR app couldn't sync new hires to AD. The user saw error 0X0000217E and thought the domain was dead. It wasn't. The app was sending a LDAP search with both a paging control and a sort control at the same time. Active Directory can't handle that — it's like putting both your foot on the gas and the brake. The OS throws this error when you use multiple server-side controls on one operation that are incompatible. Common in custom scripts, old VB apps, or PowerShell code that stacks filters.
What triggers this?
You'll see this error when:
- Your code uses both
LDAP_SERVER_PAGED_RESULT_OIDandLDAP_SERVER_SORT_OIDin the same search - A third-party AD tool tries to combine show-deleted with a sort control
- You're running a bulk query via ADSI that includes both a range retrieval and a sort
I've also seen it happen with old HP printer management software that used two overlapping search filters. The fix was to update the software, but we got it running by changing the LDAP control order once.
Step-by-step fix
- Find what's sending the request. Open Event Viewer (eventvwr.msc) and check Application and Directory Service logs for the source app or script name. Look for event ID 1280 or 1091.
- Check your LDAP filter. If it's a PowerShell script, look for lines that call
Get-ADUserorSearch-ADAccountwith-ResultPageSizeand-SearchBasetogether with-Properties. Run it step by step:
will break if you also try to sort server-side. UseGet-ADUser -Filter * -ResultPageSize 100 -Properties * | Sort-Object NameSort-Objectclient-side instead. - Remove one control. Decide which control you actually need. Paging is usually needed for large results. Sort is often a client-side job. Remove the sort control from your LDAP control list. In PowerShell, that means not using
-ServerSideSortif you're using-ResultPageSize. - Test with a simple query. Use LDP.exe (built into Server) or ADSI Edit. Do a quick search for one user:
If that works, your script has the conflict. Slowly add controls back until it breaks again.cn=testuser,dc=domain,dc=com - Check third-party apps. If it's not your script, update or reconfigure the app. Look in its config XML or INI for lines like
LDAPControls=1.2.840.113556.1.4.319,1.2.840.113556.1.4.473— those are paging and sort OIDs. Remove one.
Alternative fixes if main fix fails
If you can't change the script or app:
- Use a different LDAP client. Switch from ADSI to System.DirectoryServices.Protocols in .NET — it lets you control order and choose client-side sorting.
- Change the LDAP control order. Some apps work if you put paging before sort. Try swapping the order in the control array. But this is a hack, not a real fix.
- Upgrade the app. Last client had a 2012-era backup tool that sent two sort controls. Vendor's patch fixed it. Check for updates.
Prevention tip
Never use server-side sort with paging in the same LDAP query. Sort on the client side after you get results. Also, test all new scripts on a test DC first. I keep a dedicated VM for that. One hour of testing saves you a call at 2 AM.
Was this solution helpful?