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.



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:


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

Related KB’s:

 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:


$web=get-web “specifytheurlofthewebapplication”



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;
                Console.WriteLine("The process has completed successfully");



Comments (8)

  1. I was looking for this information for months!

    GREAT JOB!!!!


  2. Brandi Hager says:

    We were having the some latency issues resolving users from people picker so we applied this fix.  When doing so, it broke a few other components such as the SP address list.  You could search for users by first name, but could not find them by last, and many other inconsistencies, etc.  Also, it broke some of the drop downs in list and other items.  The good news is names started resolving instantly rather than having the delay of search across forest and domains.  Just beware of other issues.  We had to roll ours back as the address list feature is extremely important to our users.  Apparently, we will need to find the solution if this is now part of Oct. CUs.  Any suggestions?

  3. Russ Maxwell says:

    Hey Brandi,

    I apologize but I'm not familiar with any issues encountered as a result of implementing the above fix.  I would create a support incident with Microsoft so we can investigate further.


  4. BlueSky2010 says:

    Hi Russ,

    Great information – I've been baffled with this for long. Why permissoining SharePoint groups takes forever (in both 2007 and 2010 environments).

    Can you confirm whether ActiveDirectoryRestrictIsolatedNameLevel property NOT available in SharePoint 2007? I could not find any equivalent STSADM command (I've August 2010 CU applied).

    Appreciate your feedback on this.

    Many thanks in advanced!

  5. BlueSky2010 says:

    Hi Russ,

    Could you correct the $web=get-web “specifytheurlofthewebapplication”

    part in your PowerShell script? It seem to be $web=get-SPweb instead.

    This blog post was of very help in our situation.

    Many thanks!

  6. john says:

    Hi Russ

    Great post. i am trying to understand what trace/dump i need to collect that will let me know function call time of "System.Security.Principal.NTAccount.TranslateToSids(System.Security.Principal.IdentityReferenceCollection, Boolean ByRef" .

  7. Athi Haran says:

    Guys we had the same issue, the fix was top reboot the SharePoint server, this resolved the performance issue immediately,

    I still do not know the root cause, we also using load balancer on our network, may be that may be causing this issue??

    If this is a SharePoint config thing why does it work normally after a reboot ??  very confusing

  8. viswa says:

    Hi Issue is resolved.. you did a great job…Russ Maxwell

Skip to main content