Replace The Default SharePoint People Picker With A Custom People Picker

At a recent customer of mine the question came up as to how we could replace the default people picker with a custom one that was tailored to some very particular AD queries to supplement the SharePoint calls. I read a few posts about replacing it across the board, notably this one:

which for the most part is accurate. But this looked like a lot of work.

Reflecting on how a majority of the security assignment stuff happens, the AvlInc.aspx page out of the Layouts directory is the primary workhorse. While modifying such pages out of the 12 hive isn’t technically the best route in terms of surviving updates and service packs, proper noting of the customization to re-integrate back was fine for my requirement.

That being said, after you get a custom picker working ala using inheritance for requisite SimpleQueryControl, PickerDialog, EntityEditorWithPicker classes to override the abstract inherited members with your own behavior, even if you replace the default picker on the page it will not work since the page is querying for a picker with id userPicker. You won’t be able to simply change your custom control to this id and expect it to work because the base type casting will not be supported, thus will throw a nasty error.

The easiest way around it is to toggle the visibility of the primary, OOB picker on the page to not visible, and then create your own code behind page for the AclInv.aspx. This will allow you to interrogate the accounts in the custom picker, copy them to the OOB picker, and then submit the changes (as a note, I am only concerned with one account being in the picker at a time). Once this is done change the page to look at your custom page for it’s code behind. In order to copy the accounts, you have to override the default Validate logic since you are trying to catch the account changes on the button click. To get the control on the page, you are not going to be able to use the orthodox FindControl method, but rather have to recursively search for the control using the Page root as a starting container.

public class test : Microsoft.SharePoint.ApplicationPages.AclInv
public override void Validate()
var control = (CustomEditorType) FindControlRecursive(Page, “userPicker1”);
foreach (string account in control.Accounts)
userPicker.CommaSeparatedAccounts = account;

public static Control FindControlRecursive(Control container, string name)
if ((container.ID != null) && (container.ID.Equals(name)))
return container;
return (container.Controls.Cast().Select(
ctrl => FindControlRecursive(ctrl, name))).FirstOrDefault(
foundCtrl => foundCtrl != null);


Not saying this is 100% great, but as a proof of concept is accuratish.


Best Practices For Unique Permissions On List And Items in SharePoint 2010

There are some general recommendations to consider when it comes to unique permissions in SharePoint 2010. They include:

  • Minimizing the use of unique permission on individual items. They will simplify list design to require more items for unique permissions.
  • When unique permissions are necessary, set them only at the list or folder level. Minimize the number of individual items that you need unique permissions for.
  • Reconsider your design for each item required with individual permissions. It may be a good idea to divide items between multiple lists so that they can be organized with other items into groups and folders. The proper access needs to be authorized for that unique permissions can be allowed on each item.

Granular permissions can affect performance and they are also very hard to manage. Therefore, you should leave them set at the defaults, you certainly don’t want to set them to where the list view threshold is exceeded. If you do so they will be blocked due to too many individual items being updated at the same time. Setting granular permissions can affect performance in many other ways too. The result is that there is a configuration limit by default to 50,000 unique permissions for each of the lists.

When you try to declare unique permissions after you reach that limit, you will be blocked from doing it. The list view threshold doesn’t have that block in place and it will allow you to continue to create unique permissions for each item but not for a query. Permissions can be inherited but also broken for the items when they are in a folder. There they will be considered one unique permission.

Every time a permission inheritance is broken then a new scope ID is developed. When you query on a view you can JOIN the scope table for that query. There is then unique access control over the list that has to be processed. When there are many unique permissions in a list then it can reduce the overall performance of the query so that isn’t recommended. The number of unique permission in a list gets bigger over time and that reduces the performance. While the limit is by default 50,000 it is ideal if you make your customized limit 5,000.