TLDR: This can also be caused by a mismatch in security policy “Network Security: Configure encryption types allowed for Kerberos“.   Consider the following scenario: You have a web site set up to use Kerberos authentication. It doesn’t matter what kind of site, but we’ll say it’s a SharePoint site, since that’s the theme around

First off, when using Active Directory Import in SharePoint 2013, 2016, and 2019, it’s completely normal to see very few (like 2) mapped properties in the User Profile Service Application (UPA) | Manage User Properties. That’s because with AD Import, those property mappings are hard-coded and not shown on that page. See my other post

Problem: Intermittently users notice that they have automatically been logged in as a different user. For example, while browsing, you look in the upper right-hand corner of the page and see another users display name listed there. Clicking around more may result in switching back to yourself, or switching to another user altogether. Possible Causes:

This is going to be very similar to another recent post: https://joshroark.com/sharepoint-2016-2019-timer-jobs-with-contentdatabase-lock-type-do-not-run/. In that case, timer jobs with lock type “ContentDatabase” would not run because no server in the farm has its AllowContentDatabaseJobs property set to “true”. In this case, Timer jobs with LockType = “Job” and IsServiceJob = “True” will not run because no

In SharePoint 2016 and 2019, you may find that some timer jobs are not doing what they should. In timer job history, you may see that the timer jobs are running successfully, but they aren’t doing anything. Depending on the timer job, this can be a little difficult to detect. Of the timer jobs affected

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