SharePoint: All about non-imported user profiles

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?

There are a few ways to create user profiles that are “unmanaged”. I will list them here from most common to least:

1. Users just browsing to their profile page or mysite. If a user tries to access any user profile-related pages, and they don’t already have a user profile in the UPA, one will be created for them automatically. This will be a “stub” profile with a limited set of data for the user.
2. From a different farm or different UPA. You example, maybe you had profiles imported in a SharePoint 2013 farm. If you then migrate that UPA to a 2016 farm, but you don’t select all the same OUs / containers that you had in the 2013 farm, all of the users that live in the containers you missed will become “unmanaged profiles”.
3. 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.
4. By a 3rd party. This is really just a variation of #3, but 3rd party solutions (Newsgator comes to mind in particular) can create profiles programmatically.

What’s the harm?

There’s not much really. The main ticket generator that we see is that someone will notice that a certain users profile shows up in people search results, or in the organization chart, or somewhere else unexpectedly. They may be considered “unexpected” for one of several reasons:

• 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.

A second scenario we see is that a profile that belongs to a valid user will not be getting any updates from Active Directory. For example, their title changes in AD, but stays the same in their user profile. This will happen if their profile is “unmanaged”. Since it’s not being Synched, it won’t get any updates from AD.

What to do?

Depends on what your goal is for these profiles. You’re typically going to have one of these two objectives:

Option 1: Turn them into “managed” profiles so profile import / sync can update and maintain them.

If you intended these user profiles to be imported, but they weren’t (and therefore were created as “stub” profiles) then you need to start by determining why they were not imported. We also refer to this condition as being “out of scope” for the import. There are only a few reasons:

1. 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.

   Seriously, don’t assume, go check. You can use the following PowerShell to look up a given user and output their Distinguished Name (DN):

$accountName = "josh"
$prop = ([adsisearcher]"samAccountName=$($accountName)").FindOne().Properties
$prop.displayname
$prop.distinguishedname

The output will look something like this:

Josh Roark
CN=Josh Roark,OU=Admins,OU=MyUsers,DC=joroar,DC=local

The part of the DN starting with “OU” indicates the container this user exists in. To import this user, I would need to select that container (“Admins”). Selecting its parent container (“MyUsers”) by default, will also select any child containers and will also result in the user being imported.

2. 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.

3. 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. This happens if the LastKnownParent attribute is set to an OU that is not selected for import. In that case, the users are silently ignored during import. For example:

If the “MyUsers” OU is not selected for import, this user will not be imported. Your options are to either select the indicated OU for import, or remove the value for lastKnownParent from the user object.

You can use the “CheckNonImportedProfilesAgainstAD.ps1” script from another blog post I wrote to check the users DN, their enabled / disabled status, and their value for LastKnownParent: https://joshroark.com/sharepoint-why-are-active-users-returned-by-getnonimportedobjects/

Note: It is not necessary to delete these “stub” profiles first. If a profile was first created as a “stub” / “unmanaged” / “non-imported” profile, but then later profile import / sync pulls that user in, the existing profile will be updated by the sync, and will become a “managed” profile from that point forward.

Option 2: 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:\temp\NonImportedProfiles.txt

Then go have a look at the NonImportedProfiles.txt file.

The GetNonImportedObjects flag will only return unmanaged / “stub” profiles. If a user account is in this list, it means they were most certainly not imported, so if there’s any question as to whether or not a certain user has been imported by AD Import / Sync, these results should be definitive.

If the contents of NonImportedProfiles.txt looks like the list of user profiles you’d like to remove, then you can run this:

$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 that GetNonImportedObjects returned as “ready for deletion”. 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.