InfoPath forms + People Picker fields + SharePoint groups = SLOW

Introduction into Problem

I had an interesting issue with People Picker performance and SharePoint 2007 that is deserving of some additional documentation.   As many of you know, the people picker is built in feature of SharePoint and assists in looking up users to perform various tasks like adding to AD and/or SharePoint security groups etc…   The people picker also has a control that is used in custom InfoPath forms for use in SharePoint. 

In this particular problem, InfoPath forms contained one or more people picker fields in a Form Library on SharePoint 2007.  

In this case, Participation Not Required is a SharePoint security group.

At various times, attempting to open these InfoPath forms from a forms library within SharePoint would cause an excessive delay, (30 seconds to 2 minutes).  Some dump analysis revealed we were waiting on this function to complete:

System.Security.Principal.NTAccount.TranslateToSids(System.Security.Principal.IdentityReferenceCollection, Boolean ByRef)

The object being passed was the group specified within people picker field on the InfoPath form.  In this particular case, the group was a SharePoint security group.

Cause

The problem is that we will always go to Active Directory first by default to do the lookup via the TranslateToSids function.  This isn’t desirable in this specific case because it’s a SharePoint security group that’s being passed.  The second part of the problem is with the format of the name specified on the people picker field.  The fact that there is no \ in the name causes Active Directory to submit the lookup against every domain in the forest.  In a large Forest, this can become a taxing operation.  Finally, the lookup is resolved within SharePoint.

Work Around

The good news is that we exposed a property that controls how this validation takes place when no \ is present in the name.  Instead of first going to AD, we will perform the lookup within SharePoint first.  This is desirable in certain scenarios such as this one.  Names containing domain\username will still be processed by Active Directory first so no affect their.  The property is the following:

ActiveDirectoryRestrictIsolatedNameLevel

http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.sppeoplepickersettings.activedirectoryrestrictisolatednamelevel.aspx

We exposed this property in the October CU so the SharePoint 2007 farm must be at build 12.0.6520.5000

Related KB’s:

http://support.microsoft.com/kb/976396

http://support.microsoft.com/kb/975002/

 This property is set on the Web Application level and is false by default.   In order to work around the problem, set this property to true.   A few ways for doing this:

PowerShell:

$web=get-web “specifytheurlofthewebapplication”
$web.Site.WebApplication.PeoplePickerSettings
$ps=$web.Site.WebApplication.PeoplePickerSettings
$wa=$web.Site.WebApplication
$ps.ActiveDirectoryRestrictIsolatedNameLevel=$true;
$wa.Update();

C#:

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.SharePoint.Administration;
using Microsoft.SharePoint;

namespace PeoplePick
{
    class Program
    {
       static void Main(string[] args)
        {

            SPSite oSite = new SPSite("http://moss");

            SPWebApplication myweb = oSite.WebApplication;
                SPPeoplePickerSettings ppSettings = myweb.PeoplePickerSettings;
                ppSettings.ActiveDirectoryRestrictIsolatedNameLevel = true;
                myweb.Update();
                Console.WriteLine("The process has completed successfully");
        }

-Russmax