0X0000217E

ADSI conflict error 0X0000217E fix

Windows Errors Intermediate 👁 4 views 📅 Jun 29, 2026

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_OID and LDAP_SERVER_SORT_OID in 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

  1. 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.
  2. Check your LDAP filter. If it's a PowerShell script, look for lines that call Get-ADUser or Search-ADAccount with -ResultPageSize and -SearchBase together with -Properties. Run it step by step:
    Get-ADUser -Filter * -ResultPageSize 100 -Properties * | Sort-Object Name
    will break if you also try to sort server-side. Use Sort-Object client-side instead.
  3. 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 -ServerSideSort if you're using -ResultPageSize.
  4. Test with a simple query. Use LDP.exe (built into Server) or ADSI Edit. Do a quick search for one user:
    cn=testuser,dc=domain,dc=com
    If that works, your script has the conflict. Slowly add controls back until it breaks again.
  5. 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?