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 outside of profile import / sync.  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, one will be created for them automatically.  This will be a “stub” profile with a limited set of data for the user.
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?

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.

What to do?

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

-- 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:
  • 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:
Note: you do not have to delete these “stub” profiles first.  If a profile was first created as a “stub” / non-imported profile, but then later profile import / sync imports that user, the existing profile will be updated by the sync, and will become a managed profile from that point forward.

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

Comments (0)

Skip to main content