Consider the following scenario: You have a fairly large and / or complex Active Directory (AD) infrastructure.When using People Picker in a SharePoint 2013 or 2016 site, you are unable to find users from certain domains, and eventually the People Picker control displays an error: “Sorry, we’re having trouble reaching the server”. You do some
SharePoint: Person or Group column does not display expected results when limited to a SharePoint group
Consider the following scenario: You have a SharePoint list with a Person or Group column.This column is limited to choose from a SharePoint group called (for example) Approvers. Within this SharePoint group, you have three users with (for example) first name Jeff, and one user with last name Jefferson. Within the person or
Some potential symptoms: You try to add a user to a SharePoint group. The account is added without error, but it doesn’t show up in the group. You try to add a user to a “person or group” column in a list. The account is added successfully, but it doesn’t show up in the list.
This is one that has plagued SharePoint admins since SharePoint 2007 and earlier. There are a few other posts out there that mention this behavior, but as far as I can tell, none of them offer a complete solution. Consider the following scenario: The SharePoint farm exists in DomainB.You have users in DomainA.You migrate those
Often in troubleshooting SharePoint, we’re interested to know on which Web-Front-End (WFE) a certain request landed. When you have multiple WFEs that are load balanced, this is not easily discernable. One trick is to edit your HOSTS file and point the load balanced URL at the IP address of one WFE. That method certainly has
NTLM authentication is not great. It’s not the fastest. In most cases, that honor would go to Kerberos. It’s not the most secure. Again, Kerberos. It’s not all that flexible. For example, it doesn’t work well for extranets or anything cross-firewall. In those scenarios, Trusted Provider auth (SAML / WS-Fed) works well. See: AD FS.
I find there is much confusion around this topic, so I’ll try to clear it up here. First off, non-imported profiles are well… not imported. They were not created by Profile Sync / AD Import / Sync with External Identity Manager. We also refer to these as “unmanaged”, or “stub” profiles because they typically only