Category: SharePoint 2019

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

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

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