Today, I’d like to post about a behavior in SharePoint that has a dramatically impact on performance!
Consider this scenario:
You go to the people picker to search for let’s say: “User42”. You wait for about more than 3.5 min. until the results are displayed.
You’d now check if there is a general problem and trying it again with a simple repro on the file system as follows
– chose any folder on your hard disk, right-click and chose “properties”.
– “add” the wanted User as you would like to do it on granting permissions to this folder.
– Note, that this is taking less than a second(!) to resolve and adding the named User, how this?
So on setting the ULS logging to “verbose” level and retry the peoplepicker search, we will find some interesting hints like this in our logs:
| […] 01.31.2011 15:50:13.98 w3wp.exe (0x1010) 0x163C SharePoint Foundation Performance ftq2 Verbose SearchFromGC name = corp.lan. returned. Result count = 0 21e10f56-2f45-4a29-a53c-4fda5da9f117 01.31.2011 15:50:13.98 w3wp.exe (0x1010) 0x163C SharePoint Foundation Performance ftq1 Verbose SearchFromGC name = contoso.com. start 21e10f56-2f45-4a29-a53c-4fda5da9f117 01.31.2011 15:50:30.12 w3wp.exe (0x1010) 0x163C SharePoint Foundation Performance ftq3 Verbose SearchFromGC name = contoso.com. Error Message: A local error has occurred. 21e10f56-2f45-4a29-a53c-4fda5da9f117 01.31.2011 15:50:30.12 w3wp.exe (0x1010) 0x163C SharePoint Foundation General 7fbh Verbose Exception when search “user42” from domain “contoso.com”. Exception: “A local error has occurred. “, StackTrace: ” at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail) at […] 01.31.2011 15:50:30.12 w3wp.exe (0x1010) 0x163C SharePoint Foundation General 72e7 Medium Error in searching user ‘user42’ : System.DirectoryServices.DirectoryServicesCOMException (0x8007203B): A local error has occurred. at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail) at […] 01.31.2011 15:50:30.12 w3wp.exe (0x1010) 0x163C SharePoint Foundation Performance ftq1 Verbose SearchFromGC name = de-corpx.com. start 21e10f56-2f45-4a29-a53c-4fda5da9f117 01.31.2011 15:51:12.95 w3wp.exe (0x1010) 0x163C SharePoint Foundation General 72e7 Medium Error in searching user ‘user42’ : System.Runtime.InteropServices.COMException (0x8007203A): The server is not operational. at […] 01.31.2011 15:51:13.08 w3wp.exe (0x1010) 0x163C SharePoint Foundation Performance ftq2 Verbose SearchFromGC name = my-group.biz. returned. Result count = 0 21e10f56-2f45-4a29-a53c-4fda5da9f117 |
CAUSE:
For any given search string, i.e. “User42” (which is NOT typed in as “Domainusername” or as UPN “user42@mydomain.com”) the Query fetches the account details (SearchFromGC) for the user.
The GetAccountName() function is then used to convert the SID returned by the LDAP query.
The GetAccountName() results in LSASS calling LsarLookupSids3 (when using People Picker) OR both LsaLookupNames4 + LsarLookupSids3 (when using “Check Names”).
So we see that we do get the result back from LDAP with the result set and then we use that result set’s SID to get the account name in the format DOMAINUSERLOGIN. The LDAP resultset has this information in the LDAP format, but not in the expected format for SharePoint. This is why we call GetAccountName() to resolve the SID into the Account name.
This process takes a long time and impacts the performance for People Picker / CheckNames function as well as in addition waiting for each timeout on not reachable DC’s.
So by using “Isolated Account Names” on peoplepicker search, performance decreases as the number of trusted domains increases…
See more on http://support.microsoft.com/kb/818024
RESOLUTION/WORKAROUND:
Use the stsadm commands for setting the properties to be limited on a particular Domain (where the user lives) and the specific Domain under your Forest on a multi trusted AD environment.
stsadm -o setproperty -url http://<WebAppName> -pn peoplepicker-distributionlistsearchdomains -pv <domainname>
stsadm –o setproperty –pn peoplepicker-searchadforests –pv domain:<domainname> -url http://<WebAppName>
.gif) Note: |
|---|
| By default, SharePoint talks to the domain controller for the domain in which SharePoint was installed and all trusted domains for two-way trusted domains. |
Remarks:
The above commands will enable a limited search against a dedicated domain where the wanted user account resides.
So when having user accounts from other domains in addition, these domains must be also set according to the above command for each needed domain name.
This setting is a per web application setting as defined by the -url parameter and must be also repeated for each web application further.
So by design, SharePoint will behave as of the above description but on forcing only to use the pure ldap results and defining the requested domain explicitly,
we can significant increase the performance on people picker search results near to less than 2 seconds!
If you’re having a “one-way-trust”, then you need to run additionally this command first:
stsadm –o setapppassword -password <SomeKey>
see more details here: http://technet.microsoft.com/en-us/library/cc263460(office.12).aspx
Resources:
People Picker Overview (2010)
Peoplepicker-distributionlistsearchdomains
Peoplepicker-searchadforests
Add users from multiple forest domains
Select users from multiple forest domains
“The Server Is Not Operational” Error Message in Active Directory
SharePoint 2010 PeoplePicker Not Finding Active Directory Users
All you want to know about People Picker in SharePoint ( Functionality | Configuration | Troubleshooting ) Part-1
All you want to know about People Picker in SharePoint ( Functionality | Configuration | Troubleshooting ) Part-2
Hope, that helps you if having this issue.
cheers, Steve
SharePoint mysteries and more... 
Steve, Thank you very much for this blog, this helped a lot to resolve the PP performance issue.
I have just one question, we never had this issue before all this happened after installing Service Pack 2 and December 2014 CU in our environment, are they any know issues that were registered about this.
LikeLike
THANK YOU SO MUCH!
I've literally been trying to optimize my people picker for weeks.
We opened a Microsoft support ticket… and they couldn't even help us. This article was a tremendous help thank you so much.
LikeLike
Hi Steve,
We have discovered that in our multi-forest environment the number of domains specified in the peoplepicker-searchadforests property has a directly impact to the time it takes to create a standard sharepoint publishing site.
This seems very strange but the impact is dramatic.
The forest where our SP2010 farm sits has a dozen or so trusts. When we had not set the peoplepicker-searchadforests we saw that it was taking 2-3 minutes to create a pubishing site collection!
After weeks of investigations we narrowed it down to peoplepicker-searchadforests
by restricting the peoplepicker-searchadforests to search on only our domain the time to create dropped to 20 seconds!
Insane, but true. Do you have any insights on this dependancy and relation?
In reality our peoplepicker-searchadforests property is going to be set to search around a dozen geographically dispered domains. each domain adds 10-15 seconds to the site creation time
Do let me know if there is more information on this strange but troubling issue
regards,
Amir Khan
LikeLike
Hi Steve,
is it possible that these settings will take effect to the login performance?
LikeLike
Hi Steve,
is it possible that this settings take effect to the login process? Did Sharepoint looks at first in the Domain that you set via STSADM at the login process?
LikeLike
Hello MuSa,
AFAIK, there isn’t any issue reported with people picker after installing either SP2 and/or Dec. 2014 CU. So this might have another cause but just appeared by accident.
We often get issues likely caused by delayed server reboots and it often appears to be i.e a security fix that was installed long before but occurred first after the reboot. Same may happen "Out of sudden" most likely caused by delayed reboot after some configuration
changes that only takes affect after reboot.
The stsadm command to increase the PP search performance is usually not changed or reverted by a service Pack or CU.
LikeLike
Hi Frank,
I'm not sure about this, because usually SharePoint will only respect the filter once set by stsadm for the people picker and search functionality. The normal logon process should be determined as usual via validation against the first DC in the domain the sharepoint server exists.
I'm not aware of any impact on logon caused by the filter settings but if Users are form another domain than this could be also caused by the same reason as described above (DC not reachable, firewalls dropping LDAP binds, etc.).
Best way to investigate is taking a NetMon trace while logon and verbose logging turned on in SharePojnt, then verify the ULS log/Event log errors and the netmon traces for more informaiton.
See also the links below "resources" to get more information regarding "multiple forest domains, etc."
cheers, Steve
LikeLike