This is similar to a previous blog post I wrote. However, we’ve since found a few customers that have done something similar with Windows authentication.

We’ve seen this a few times now. It seems to most commonly occur when Admins are setting up a new User Profile Service app using Active Directory Import (AD Import, ADI) and try to replicate the property mappings they were previously using with User Profile Synchronization (FIM Sync) in SharePoint 2010 or 2013. Usually, a PowerShell script was used to re-create the user profile property mappings and (incorrectly) created mappings for “Claim Provider Identifier” (SPS-ClaimProviderID) and “Claim Provider Type” (SPS-ClaimProviderType).

Symptoms:

• Running a full import does not import any user profiles or update existing profiles.
• User profiles that were previously imported may be marked for deletion (“Profiles Missing from Import”).
• You may see an error like this in the SharePoint ULS logs when the import timer job runs:

  OWSTIMER.EXE (0x3EA0)    0x31B0    SharePoint Portal Server    User Profiles    aei8n    High    ProfileImportExportService.UpdateWithProfileChangeData: Uncaught exception for object ‘8b97decf-30b1-4f50-8e23-6b1c21ea8d10 (CONTOSO\User1)’ – Microsoft.Office.Server.UserProfiles.UserProfileException: Claim Authentication Provider Type and Claim ID must be specified together.     at Microsoft.Office.Server.UserProfiles.UserProfileManager.CreateProfileWithBulkProperties(Int64 importExportId, String strAccountName, Hashtable properties)     at Microsoft.Office.Server.UserProfiles.ProfileImportExportService.<>c__DisplayClass2a.<UpdateWithProfileChangeData>b__28(Int32 idx).   
  

• Import connection container selection is empty, and changes to container (OU) selection do not commit.

That last one is the most tell-tale sign, but may require further explanation. For example, you edit the import connection and choose “Populate Containers”. You see that no containers are selected:

You select some containers, and click OK to commit the changes. You then edit the connection and do “populate containers” again. You see that all containers are still unselected. If you look in the SharePoint ULS logs at this time, you may see an error like this:

w3wp.exe (0x0A54)    0x0ADC    SharePoint Portal Server    User Profiles    7hxq    High    EditDSServer.OnLoad(): System.ArgumentOutOfRangeException: ‘drpClaimProviderType’ has a SelectedValue which is invalid because it does not exist in the list of items. Parameter name: value at System.Web.UI.WebControls.ListControl.set_SelectedValue(String value) at Microsoft.SharePoint.Portal.UserProfiles.AdminUI.EditDSServer._LoadConnectionInfo(Connection connectionDataSource) at Microsoft.SharePoint.Portal.UserProfiles.AdminUI.EditDSServer._LoadConnectionInfoInForm(String strDN) at Microsoft.SharePoint.Portal.UserProfiles.AdminUI.EditDSServer.OnLoad(EventArgs e).    847cf29e-d007-e088-a10e-e33382aa5e73

Cause:

The user profile properties “Claim Provider Identifier” (SPS-ClaimProviderID) and “Claim Provider Type” (SPS-ClaimProviderType) had property mappings manually added to them.

If you edit one of the properties, the property mapping looks like this:

That is not a valid thing to do when using Active Directory Import. Those two properties have implicit mappings created at the time the import connection is created. Manually creating mappings for those two properties overwrites the implicit mappings and generally breaks the import as noted above.

Resolution:

Unfortunately, you cannot just delete the manually-created mappings. As noted earlier, there are implicit mappings for those two properties that are automatically created when you create the import connection. They look like this:

Notice there is no attribute listed for the implicit mapping because it is mapped to a constant. This is the kind of mapping we need, but I’m not aware of any way to manually re-create that kind of mapping.

Instead, you must delete and re-create the import connection to get these mappings back. Before you do that, you’ll want to document a number of things:

1. The containers / OUs you had selected. — Once you remove the manually-created mappings for “Claim Provider Identifier” and “Claim Provider Type”, you should be able to do “Populate Containers” again, and it should show you the containers you had previously selected.

2. The LDAP filter used on the import connection page.

3. The import connection account and password.

4. Any custom property mappings you had. — The custom properties themselves and their values will not be deleted when you re-create the import connection. However, since the mappings are tied to the connection, they will need to be rebuilt after the new import connection is created.

Note: With AD Import, there are a number of out-of-box mappings that do not show in the Central Admin UI. See my previous blog post about that.

Once you have all the connection details and custom mappings documented, you will want to disable the “My Site Cleanup Job” timer job. That is just a precaution to make sure user profiles do not get deleted if you mess something up during the re-creation of the import connection.

Then you can delete the import connection and re-create it with proper LDAP filter and container selections.

Then you can re-create custom property mappings (if any).

After all that, you should be ready to run a Full Profile Import, which should fix everything up.