Category: AD Import

This is an interesting “gotcha” that came up recently: Problem: The Active Directory Import (UserProfileADImportJob) timer job does not run.  It’s enabled and scheduled to run (default every 5 minutes), but never runs.The result is that the user profiles never get imported. Cause: All the servers in the farm that are running the User Profile

Here’s one that was a problem in SharePoint 2013, was fixed, but never ported to SharePoint 2016, so we had to fix it again. Consider the following scenario: You are importing user profiles from Active Directory (AD).  This can happen using any of the profile import methods for either SharePoint 2013 or 2016. 2013: SharePoint

Many times we end up battling “SharePoint Profile Synchronization” (aka: “FIM Sync”) for a while before we realize that “SharePoint Active Directory Import” (aka: “AD Import”, aka: “ADI”) was a better fit all along. Why switch?  Or for new farms, why go with AD Import? “SharePoint Active Directory Import” (“AD Import” from here on) is

Overview: This is a fairly visible problem within SharePoint.  It can cause the organization chart to show old manager info, or not work at all.So what to do if your user profiles show no manager value, or maybe a user has changed managers, and it’s not being updated? This is a complicated topic for a

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

Update: There was a fix for this behavior in the SharePoint 2016 August 2020 Public Update (build 16.0.5044.1001), so if you’re past that build and seeing the “batch abort exception”, it’s more likely that it indicates a real problem.   Here’s an example of an error that often occurs during Active Directory Import (aka: ADI,