How to debug the SharePoint People Picker Problems
In complex environments you often have to adapt the SharePoint people picker settings for performance or other business needs reason. In this post I'll show two common problems.
One reason for that is often that the whole AD with all subtrees and trusted ADs is searched. This can be easily fixed by setting a filter to the people picker (like shown here).
Another reason can be that there are multiple Domain Controllers which the SharePoint Server tries to contact. There will be a delay if some of them are sitting behind a firewall like in a DMZ. This can be fixed by opening the ports to the DCs or by modifiying the host file, by pointing th IP of the DCs behind the firewall to DCs in front.
Replace the domain names and the web application url for your needs.
I use first a powershell script to check if I can contact the new DC. You have to know a little bit how ldap queries are working to understand the script.
Just adapt the DirectoryEntry setting and enter the login in DisplayUser( login ) at the bottom.
When this script works without any problems. I go further by digging in to the ldap traffic between the SharePoint Server and the DC.
The tool I use for monitoring the traffic is WireShark . Install WireShark on your frontend server. Start it. Select the adapter to connect and start monitoring the network traffic.
You'll see lots of traffic. Now enter "ldap" in the filterbox and click on apply to only see ldap traffic.
The next step is to create ldap traffic. Therefore open any SharePoint Site. Just go to the site actions menu and select Site Permissions. Try to search a user in the new AD. As an example I search a user with the loginname "anncle".
You will see now some traffic in the WireShark. Click on stop monitoring.
Click on Edit Menu and then on "Find Packet". Give the loginname you searched for into the search box.
Now you can see the ldap query, the time which the DC's need to respond and which DCs are contacted. With all that information it is easier to debug and find out the real problem.
In my case I check the query which the WFE send to the DC.
With right click you can copy the query and you can try and modify it with Tools like LdapAdmin.
In my case, by inspecting the ldap query I found out that I had a filter which I set prior to improve the performance. By removing the filter from the sitecollection everything worked fine.
Example 1: The people picker takes too long to find a user.
The szenario is that you search for a user and you wait 1 or longer minute before the user is displayed in the people picker.One reason for that is often that the whole AD with all subtrees and trusted ADs is searched. This can be easily fixed by setting a filter to the people picker (like shown here).
Another reason can be that there are multiple Domain Controllers which the SharePoint Server tries to contact. There will be a delay if some of them are sitting behind a firewall like in a DMZ. This can be fixed by opening the ports to the DCs or by modifiying the host file, by pointing th IP of the DCs behind the firewall to DCs in front.
Example 2: Your company consists of multiple branches with their own AD
You can tell the peoplepicker to search multiple domains. If you have a 2-way trusted domains, this problem can be easily fixed with a stsadm command:
stsadm -o setproperty -pn peoplepicker-searchadforests -pv "domain:germany.mydomain.com;domain:turkey.mydomain.com" -url http://sharepoint
Replace the domain names and the web application url for your needs.
How to Debug
We take the example 2. What if you set the stsadm command in the second example but you can't find any user from the other domain ?I use first a powershell script to check if I can contact the new DC. You have to know a little bit how ldap queries are working to understand the script.
Just adapt the DirectoryEntry setting and enter the login in DisplayUser( login ) at the bottom.
<#
Display user information from AD
@author: Ihsan Baris Bikmaz
#>
clear
function DisplayUser($cn) {
$strFilter = "(&(objectClass=User)(cn=$cn))"
$objDomain = New-Object System.DirectoryServices.DirectoryEntry("LDAP://OU=Users,DC=turkey,DC=mydomain,DC=com")
$ds = New-Object System.DirectoryServices.DirectorySearcher
$ds.SearchRoot = $objDomain
$ds.PageSize = 1000
$ds.PropertiesToLoad.Add("displayName")
$ds.PropertiesToLoad.Add("co")
$ds.Filter = $strFilter
$ds.SearchScope = "Subtree"
$retArray = @()
Write-Host " >> Searching for User with cn: " $cn
$ds.Findall() | Sort Path | ForEach-Object {
$dname = $_.Properties.Item("displayName");
$element = New-Object System.Object
$element | Add-Member -type NoteProperty -name CN -value $cn
$element | Add-Member -type NoteProperty -name Name -value $dname
$retArray += $element
}
$retArray
}
$myArray = @()
$myArray += DisplayUser("abikes")
$myArray
When this script works without any problems. I go further by digging in to the ldap traffic between the SharePoint Server and the DC.
The tool I use for monitoring the traffic is WireShark . Install WireShark on your frontend server. Start it. Select the adapter to connect and start monitoring the network traffic.
 |
| Start WireShark |
 |
| Apply LDAP Filter |
The next step is to create ldap traffic. Therefore open any SharePoint Site. Just go to the site actions menu and select Site Permissions. Try to search a user in the new AD. As an example I search a user with the loginname "anncle".
You will see now some traffic in the WireShark. Click on stop monitoring.
 |
| Stop monitoring |
 |
| Find Packet |
Now you can see the ldap query, the time which the DC's need to respond and which DCs are contacted. With all that information it is easier to debug and find out the real problem.
In my case I check the query which the WFE send to the DC.
 |
| Ldap Query |
With right click you can copy the query and you can try and modify it with Tools like LdapAdmin.
In my case, by inspecting the ldap query I found out that I had a filter which I set prior to improve the performance. By removing the filter from the sitecollection everything worked fine.
Comments
sorry never had that before. There is also no add button on the people picker. Which button do you mean exactly? There are two one with the head and the other with the address book.
I checked the code for the picker. There is no permission check or something else. It is a javascript function that enables the button:
"function PickerDialogUpdateAddSelectionButton()
{
var objAddSelButton = document.getElementById('ctl00_PlaceHolderDialogBodySection_AddSel');
if (objAddSelButton != null)
{
objAddSelButton.disabled = (selected.length == 0);
}
}"
For me the error can be:
1.) Reading the js function you have to select in the upper box an account to enable the button. I know it's a stupid answer but sometimes it is the easiest answer.
2.) Because it is a javascript function and you say that on the server everything is fine it can be that you use different browsers, perhaps an unsupported one.
3.) You have a custom Http Handler on your SP Server which perhaps blocks the loading of some scripts like the /_layouts/entityeditor.js file.
Other question: Can you search after users ? And are they resolved when you press enter in the search box ?
Sharepoint Developers