Some Background: Since pretty much the beginning of SharePoint, user profile synchronization has been a two-step process: 1. Import user data from Active Directory to the User Profile Service Application (UPA). 2. Push that user data from the UPA down to each site collection. Step 2 is our focus here, and is automatically done by

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

Note: This also applies to on-premise versions of SharePoint (probably — I didn’t test them all), although the PowerShell used to export list data would be different in that case. Consider the following scenario: You have a SharePoint list that you’ve been using for some time and contains many records. You decide you want to

I’ve put off writing this post for a long time, hoping that the User Profile Synchronization service (aka: FIM Sync) would go away. And it is going away with the eventual retirement of SharePoint 2010 and 2013, but that’s not happening soon enough, and meanwhile we’re still seeing a lot of support cases on it.

As lame as this sounds, there have been a few (rare) situations where trying to do something with a Windows-Claims web application within Central Administration fails with an Access Denied (sorry, this site has not been shared with you) error due to lack of permissions for your Windows Classic authentication account. If you find a

Consider the following scenario: You configure Active Directory Import (ADI) within SharePoint 2013, 2016, or 2019. You make some custom user profile property mappings. You run a Full import. You notice that users have odd values with their SIP Address user profile property. For example:     Or maybe it has an “SMTP:” prefix like

Often while troubleshooting authentication or permission problems, you need to see the actual account name for the user or group added to permissions. This is particularly important in SAML / Trusted Provider authentication because the way the claim is being passed in the SAML assertion must match exactly with the way claim has been added