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)))
ctrl => FindControlRecursive(ctrl, name))).FirstOrDefault(
foundCtrl => foundCtrl != null);
Not saying this is 100% great, but as a proof of concept is accuratish.