Category: People Picker

Important: This is not something that is supposed to work. You’ll see that we can get it to work in certain scenarios, but it is not an intended design of SharePoint. At any time, a code change could be made that breaks our workarounds and leaves little recourse other than enabling the accounts in Active

  Consider the following scenario: You have a SharePoint 20xx (doesn’t matter) site and have configured People Picker to search a trusted Active Directory Forest or Domain. You have a security group of type “domain local” in the trusted forest that has several users in it. You use People Picker to search for the group,

This one is likely to be somewhat rare, but when it happens, the logging doesn’t give you many clues outside of the original “user does not exist or is not unique” error, which is pretty generic. I have two other posts about the same error with different root causes: https://joshroark.com/sharepoint-people-picker-error-user-does-not-exist-or-is-not-unique-similar-account-names/ https://joshroark.com/sharepoint-quick-edit-with-people-picker-field-the-user-does-not-exist-or-is-not-unique/   Symptoms: When using

Update 8/13/20 – Added info about RPC Endpoint Mapper Client Authentication, which can break people picker in forest trust scenarios. Consider the following scenario: You have your SharePoint servers in the “Contoso.com” domain. You have the peoplepickersettings.searchactivedirectorydomains (SearchADForests) People Picker property configured properly to search trusted forest “fabrikam.net”. You search for a user that exists

Poor people picker performance is usually caused by one of two things: 1. People Picker (hereafter abbreviated as PP) is connecting to a Domain Controller across a slow network link. 2. People Picker is trying to query domains that are not available on the network (usually due to firewall settings). Note: If PP performance is

We’ve seen a few of different problems occur in SharePoint (2013, 2016, 2019) when users are being migrated from one domain to another. They usually come up in one of the following areas: People Picker People Picker may show either or both accounts depending on which domain SharePoint is in, and how PP is configured

Today I’m writing about a little-known SharePoint People Picker property that can influence your People Picker results. First some background: In SharePoint 2010, People Picker searched all two-way trusted Active Directory (AD) forests by default. In SharePoint 2013 and above, only the local forest is queried, but similar to Exchange, we also leverage the mxExchMasterAccountSid