Category: AD Import

SharePoint: Unexpected values in user profile SIP Address property

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

SharePoint – AD Import – Some users are not imported

The most common reasons for some users not getting user profiles imported when using SharePoint Active Directory Import (AD Import; ADI) have been the same for a long time now. They are (in order): Container / OU selection (you didn’t select the containers that the missing users live in) LDAP Filter (your filter excludes those

SharePoint: Why are active users returned by GetNonImportedObjects?

As discussed in my previous posts about user profile cleanup for SharePoint 2013 and SharePoint 2016, when using Active Directory Import, the profile cleanup process is a bit more manual as compared to FIM Sync. It consists of three steps that need to be done periodically to keep things cleaned up: 1. Run a Full

SharePoint: The complete guide to user profile cleanup – Part 5 – 2019

  As far as I know, nothing much has changed regarding profile cleanup in SharePoint 2019 as compared to SharePoint 2016. See that post: SharePoint: The complete guide to user profile cleanup – Part 4 – 2016       This is part 5 in a series. You can find other parts here: SharePoint: The

SharePoint: Active Directory Import with Trusted Provider authentication: Map only Claim User Identifier

  Summary: You do this a bit differently than when using FIM Sync. When using Active Directory Import (AD Import) with SharePoint 2013, 2016, 2019, etc, only the “Claim User Identifier” (SPS-ClaimID) profile property needs to be mapped manually.  “Claim Provider Identifier” (SPS-ClaimProviderID) and “Claim Provider Type” (SPS-ClaimProviderType) are mapped automatically when you create the

SharePoint: Cross-forest group memberships not reflected by Profile Import

Consider the following scenario: You have an Active Directory Forest trust between your local forest and a remote forest. You create a “domain local” type security group in Active Directory and add users from both the local forest and the remote trusted forest as members. You configure SharePoint Profile Synchronization to use Active Directory Import