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
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