Refining People-Picker

Refining The SharePoint People-Picker

In SharePoint there are several locations where a set of users is presented in what is known as the “People-Picker”. Examples include a “people” field in lists, and in assigning security.

One can manage the set of users and groups presented, however THe underlying mechanism is not well known in the SharePoint community. In short, it is the set of all users returned from AD (ActiveDirectory) plus the set of local users in the Site Collection being used.

In this article, I’ll provide guidance on how to adjust both the users returned from AD, as well as the users in the site collection.

AD Filtering

To return a subset of AD results, the following stsadm command is used:

stsadm -o setproperty -url http ://SharePoint/  -pn peoplepicker-searchadcustomfilter -pv ""

In this example, http ://SharePoint is your web application, and the “” is the LDAP query. This clears the AD filter, as the LDAP query is empty. Note there is no PowerShell equivalent in SP2010, and this applies to a Web Application and not individual site collections. To test the change, try editing the set of Site Collection Administrators or User Policy for the Web Application in Central Administration.

In the example below, an LDAP query is specified to select AD entries where users have a manager (which filters out all kinds of non-standard user accounts), and groups starting with “SharePoint_”.

stsadm -o setproperty -url http ://SharePoint  -pn peoplepicker-searchadcustomfilter -pv "(|(&(objectcategory=group)( sAMAccountName=domainsharepoint_*))(&(&(objectcategory=person)(objectclass=user))(manager=*)))"

Let’s check out the LDAP Query string above, with this bit of PowerShell:

$strFilter = "(|(&(objectcategory=group)( sAMAccountName=yourdomainsharepoint_*))(&(&(objectcategory=person)(objectclass=user))(manager=*)))"
$objDomain = New-Object System.DirectoryServices.DirectoryEntry
$objSearcher = New-Object System.DirectoryServices.DirectorySearcher
$objSearcher.SearchRoot = $objDomain
$objSearcher.PageSize = 1000
$objSearcher.Filter = $strFilter
$objSearcher.SearchScope = "Subtree"
$colProplist = "name"
foreach ($i in $colPropList){$objSearcher.PropertiesToLoad.Add($i)}
$colResults = $objSearcher.FindAll()
foreach ($objResult in $colResults)
{$objItem = $objResult.Properties; $}

ColResults now has a nice array of results to work with.

While the above is all straightforward, the results in PeoplePicker could be less than perfect. If you test, the users returned may contain additional users, including those not returned by the LDAP Query.

It turns out, People Picker returns the superset of the LDAP Query results AND a local user list that is cached in a site collection. You can see this list by going to the Site Collection URL, plus this: “_catalogs/users/”. Note the default view does not allow you to delete items, but if you add a new view, you can add “Edit” as a column, and delete individual users one at a time.

The script below will delete all cached users in a Site Collection (except for Site Collection Administrators); but I don’t think you want to run it, as it will remove all user permissions as well!

$url = "http://YourSiteCollection"
$web = get-spweb $url
$list = $web.Lists["User Information List"]
$listItems = $list.Items
$listItemsTotal = $listItems.Count
for ($x=$listItemsTotal-1;$x -ge 0; $x–-)
Write-Host(“DELETED: ” + $listItems[$x].name)
remove-spuser $listItems[$x]["Account"] -web $url -confirm:$false

To get this right, we need to extract the LDAP query results into a hashtable, and loop through the cached user list and only remove entries that are not in the LDAP query.

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *