UserAccountDirectoryPath for Restricting Users seen in People Picker


  • Hi Folks,

    I am seeing a lot of conflicting advice on the web re the "UserAccountDirectoryPath" setting.

    Many blogs say to use this command via PowerShell to configure what can be seen in People Pickers.

    Microsoft gives different advice here:

    see esp. "There are no Windows PowerShell commands to configure People Picker."

    We are having considerable difficulty with this issue, could anyone advise?




    Saturday, May 05, 2012 3:59 PM


All replies

  • Correct, Microsoft doesn't provide a PowerShell cmdlet to modify this setting, but you can manipulate PeoplePicker settings via PowerShell, for example:

    Personally, I think it is easier to manipulate this via stsadm.

    Here is one for the UserAccountDirectoryPath:

    Saturday, May 05, 2012 4:17 PM
  • Great thanks for that - the difference between providing a PowerShell cmdlet and being able to manupulate via Powershell has gone over mhy head a bit - could you advise, as I am not sure what I am missing here.


    Saturday, May 05, 2012 4:48 PM
  • A cmdlet is a function that contains logic that you can execute with typically one line of PowerShell.  For example, the function behind Get-SPWeb is many lines of code, but you only have to type in Get-SPWeb -Identity http://sharepoint.  Cmdlets are also reusable, e.g. you can call them over and over again, versus having to type out multiple lines of PowerShell each time.  The first link I provided has a couple of cmdlets (the function SetAppPassword and PeoplePickerSearchADForests are cmdlets).  The second link I provided doesn't have a cmdlet, though it could be turned into one with a few more lines of PowerShell.

    Saturday, May 05, 2012 4:52 PM
  • Forgive me,  I think this is where I am failing to understand...

    Isnt "Set-SPSite" a cmdlet?

    as in:

    Set-SPSite -Identity http://demo2010a:122/my/personal/SimpleSC -UserAccountDirectoryPath "(OU=Demo2010a,OU=PSUsers,OU=PSDeep,DC=Demo2010a,DC=Contoso,DC=com)"


    Could I clarify my original question a little:

    Microsoft Technet says: ""There are no Windows PowerShell commands to configure People Picker.", so does that mean that the advice given in the link below is incorrect?

    We have tried the approach outlined in the link about but are getting weird permissions errors which seem to be a side effect of following the advice in the link.

    Thanks and sorry to ask so many follow up questions


    • Edited by PaulCHST Saturday, May 05, 2012 5:16 PM
    Saturday, May 05, 2012 5:09 PM
  • Yes, set-spsite is a cmdlet.  You can pass the useraccoutdirectorypath via this cmdlet.  In general, people picker props do not have a direct cmdlet supplied by Microsoft, but you can create your own powershell cmdlet or use powershell commands to change people picker props.

    If you're having permission issues, what are they so we can solve them?

    Saturday, May 05, 2012 6:05 PM
  • Cheers. Well, firstly I cant seem to get any sensible results with this command:

    Set-SPSite -Identity http://demo2010a:122/my/personal/SimpleSC -UserAccountDirectoryPath "(OU=Demo2010a,OU=PSUsers,OU=PSDeep,DC=Demo2010a,DC=Contoso,DC=com)"

    I set up a simple site collection for testing using the Info Worker 2010a demo VM and set up AD with OU "2010a" containing OU "PSUsers" containing OU "PSDeep", containing OU "PSDeeper".

    I then ran the PowerShell command above, I expected to find the people picker (which is in a list I created within my test site collection (http://demo2010a:122/my/personal/SimpleSC)) could only see Users in the PSDeep OU, but in fact I can only see the site collection administrators in the picklist.

    Wondering if I have got the syntax right?


    Saturday, May 05, 2012 7:01 PM
  • The command should be:

    Set-SPSite -Identity http://sharepoint/site/teamsite -UserAccountDirectoryPath "OU=Demo2010a,OU=PSUsers,OU=PSDeep,DC=demo2010a,DC=contoco,DC=com" (of course this is case-insensitive).

    Saturday, May 05, 2012 11:48 PM
  • Hi Thanks for that.

    Finally got it to work by removing the brackets and by removing the "DC" item "Demo2010a" it appears the command needs the domain name to be specified using the "DC" items rather than the Domain Controllers FQDN?

    Does that make sense?


    Monday, May 07, 2012 10:37 AM
  • The command needs the LDAP path, yes.

    • Marked as answer by PaulCHST Monday, May 07, 2012 2:01 PM
    Monday, May 07, 2012 1:07 PM
  • Thanks Trevor - I appreciate your help and patience!
    • Edited by PaulCHST Monday, May 07, 2012 2:04 PM
    Monday, May 07, 2012 2:01 PM