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 contain the minimum amount of user data - usually just the users account name.
Note: in this article, I will use the terms profile import / profile sync interchangeably. For our purposes here, it does not matter whether AD Import or FIM Sync is used to get profiles into SharePoint.
Where do they come from?
2. Created programmatically. You can use PowerShell or object model code to create user profiles. Unless you are also filling in additional data at creation time, these will be “stub”-looking profiles as well.
3. By a 3rd party. This is really just a variation of #2, but 3rd party solutions (Newsgator comes to mind in particular) can create profiles programmatically.
What’s the harm?
- They are not in an OU selected for import / sync.
- They are deleted or disabled in Active Directory.
- They should be subject to an import / sync connection filter.
What to do?
Turn them into managed profiles so profile sync can update and maintain them.
- They are in an OU that is not included in the import connection. No really, go double-check the distinguished name of the user in question, and compare against the OUs selected in your import connection. -- I've seen too many assumptions on where the user currently exists in AD and what the connection should be importing.
- They are subject to an import connection filter. This is one place where there is a significant difference between FIM Sync and AD import. The filtering is done entirely differently. AD Import uses a standard LDAP filter, so you can use tools like LDP.exe or LDAP Explorer to verify whether or not the filter in place should return the user. With FIM Sync, exclusion filters are used, so it’s a matter of understanding the filters and checking against the AD attribute values for the user.
- This is rare, but there is a known issue where if the LastKnownParent attribute is set on the user in Active Directory, it could result in the user not being imported. Read more here:
https://support.microsoft.com/en-us/help/313301
Remove them.
If you don’t want these profiles around, then you need to take some action to get rid of them.
Number one, you should not be looking to profile import / sync to fix this for you. Remember, these profiles were not imported, so the profile sync process does not manage them at all. In general, if profile sync did not create the profile, it can’t delete it either.
Get a list of non-imported profiles.
This is rather easy. Just run PowerShell like this:
$upa = Get-spserviceapplication | ?{$_.typename -match "profile"}
Set-SPProfileServiceApplication $upa -GetNonImportedObjects $true | out-file c:tempNonImportedProfiles.txt
$upa = Get-spserviceapplication | ?{$_.typename -match "profile"}
Set-SPProfileServiceApplication $upa -PurgeNonImportedObjects $true
Please note that this is all or nothing. The PurgeNonImportedObjects command will mark all of the profiles for deletion that GetNonImportedObjects returned. If there are legitimate user profiles returned by GetNonImportedObjects, then you should see the “Turn them into managed profiles…” section above for ideas on how to get them imported.
PurgeNonImportedObjects does not immediately delete the non-imported profiles. It just marks them for deletion (bdeleted = 1 in the UserProfile_Full table of the Profile database). Once they have been marked for deletion, it is the responsibility of the “My Site Cleanup Job” timer job to remove them, which is no different for "managed" profiles that have been marked for deletion by profile import / sync.