We had a weird problem at one of my customers the other day. They’d built a SharePoint 2010 farm with one web application and three site collections.
In two of the site collections, the PeoplePicker control allowed the users to select the correct folks from their Active Directory. However, for one site collection, only users that already exist in the User Information List could be resolved by the PeoplePicker:
This was accompanied in the ULS (14 hive logs) with the following message:
Error ID 72e9 Error in resolving user ‘fred’ : System.DirectoryServices.DirectoryServicesCOMException (0x8007202B): A referral was returned from the server. at
System.DirectoryServices.SearchResultCollection.ResultsEnumerator.MoveNext() at Microsoft.SharePoint.WebControls.PeopleEditor.SearchFromGC(SPActiveDirectoryDomain domain, String strFilter, String rgstrProp, Int32 nTimeout, Int32 nSizeLimit, SPUserCollection spUsers, ArrayList& rgResults) at
Microsoft.SharePoint.Utilities.SPUserUtility.ResolveAgainstAD(String input, Boolean inputIsEmailOnly, SPActiveDirectoryDomain globalCatalog, SPPrincipalType scopes, SPUserCollection usersContainer, TimeSpan searchTimeout, String customFilter) at
Microsoft.SharePoint.Utilities.SPActiveDirectoryPrincipalResolver.ResolvePrincipal(String input, Boolean inputIsEmailOnly, SPPrincipalType scopes, SPPrincipalSource sources, SPUserCollection usersContainer) at
Microsoft.SharePoint.Utilities.SPUtility.ResolvePrincipalInternal(SPWeb web, SPWebApplication webApp, Nullable`1 urlZone, String input, SPPrincipalType scopes, SPPrincipalSource sources, SPUserCollection usersContainer, Boolean inputIsEmailOnly, Boolean alwaysAddWindowsResolver).
A lot of people on the Internet seem to be having the same issues, and a lot of the advice seems to centre around setting Web Application level properties to configure the PeoplePicker.
But the problem here is not Web Application wide – it only affects one site collection.
So I decided to have a look at some of the properties on the SPSite object itself – through courtesy of PowerShell. A look at the SPSite.UserAccountDirectoryPath property showed an unexpected difference between the site collections that worked and the one that didn’t.
Here’s an example snippet to illustrate the point:
PS C:> $site = get-spsite http://brokensite.contoso.com PS C:> $site.UserAccountDirectoryPath DC=dev,DC=contoso,DC=com
The site collections that worked instead had an empty string for SPSite.UserAccountDirectoryPath. Simply updating the value of the errant site collection resolved the problem. You could also use the Set-SPSite cmdlet:
PS C:> Set-SPSite -Identity http://brokensite.contoso.com
This resolved the problem for our client. I hope you find it useful too!