SharePoint: Importing Manager property with AD Import: A Troubleshooter
Overview:
This is a fairly visible problem within SharePoint. It can cause the organization chart to show old manager info, or not work at all.
So what to do if your user profiles show no manager value, or maybe a user has changed managers, and it’s not being updated?
This is a complicated topic for a seemingly simple operation. The complications come from the differences in how profiles are imported between SharePoint 2010, 2013, and 2016, and the various Sync / Import options: FIM Sync, Active Directory Import, and External Identity Manager.
This particular article is about the Active Directory Import option in SharePoint 2013 and 2016.
Many times, I see the troubleshooting focus go to import / Sync of the direct report (DR) user. However, it’s just as likely that the problem is with the import / Sync of the Manager user.
The manager property is not just a string value containing a managers name, it's a reference to another user object. As such, the manager user object must be imported into the User Profile Service Application (UPA).
Troubleshooting manager updates
1. Get the account name for an example problem user and their manager -- or a couple of examples is even better.
2. Make sure the Active Directory containers that both the direct report user and manager user exist in are selected for import. First check in Active Directory and verify that the two users still reside in the containers that you think they should be in. Then edit the profile import connection and do "populate containers". Make sure the containers for both users are selected for import.
3. Make sure that the manager profile property is mapped. Manager is mapped out of the box, but you can’t assume that the mapping hasn’t been changed. Go to Central Admin | User Profile Service App | Manage User Properties | Manager. With AD Import, there is an interesting quirk where the out-of-box property mappings don’t show in the UI. However, that doesn’t mean they aren’t there. For the purposes of AD Import, just make sure Manager hasn’t been mapped to some other AD attribute. See more about that quirk here: https://www.harbar.net/archive/2013/02/18/Default-Active-Directory-Import-User-Profile-Property-Mappings-in-SharePoint.aspx
If you like, you can create an explicit mapping to the manager attribute in AD. That won’t hurt anything, it’s just redundant.
4. Make sure that the DR user and Manager user both have profiles in the User Profile Service Application (UPA). You can do this in Central Administration, but I find you can get the bigger picture by running this SQL query against the Profile database and getting the output in Excel:
select * from upa.userprofile_full (nolock)
Then you can filter and sort the data anyway you like.
5. If they don’t both have profiles, then something is wrong with the AD Import configuration. Check the Organizational Units (OUs) selected and the import connection filter to make sure they aren’t being excluded. Make sure the entire OU is selected. If just individual users and groups within the OU are selected, but the OU itself is not, that won’t work. Also, there’s a little known issue with the LastKnownParent AD attribute that will cause profiles to not be imported. Read more about that here: https://support.microsoft.com/en-us/help/3133015
6. If they do have profiles, make sure they were actually imported and are not “stub profiles”. See my article about “stub profiles” here. You can check for stub profiles by running the GetNonImportedObjects command and making sure the DR user and Manager user are NOT listed in the output text file:
$upa = Get-spserviceapplication | ? {$_.typename -match "profile"}
Set-SPProfileServiceApplication $upa -GetNonImportedObjects $true | out-file c:\temp\NonImportedProfiles.txt
7. If either the Manager or the DR is in that GetNonImportedObjects output, then we need to look at the import configuration again. We need to check OUs selected and import connection filters to make sure they aren’t being excluded from the import. You can also review the SharePoint ULS logs during a run of the AD Import timer job. More on that later.
8. If you’re here, that means you’ve confirmed that both the manager and the DR have profiles and they’ve both been imported. That means there is likely a problem with the post-import processing. After Import, manager references are staged in the upa.ProfileImportStagingPersonProperties table in the Profile database:
When the Post-import processing runs, it should clear out this table, so if there are any records that persist, that indicates a problem with the post-processing.
9. Run some SQL queries against the Profile DB to see where it's at with the post-import processing:
#-- Staged Managers:
select * from upa.ProfileImportStagingPersonProperties (nolock)
#-- Processed Managers:
select * from upa.userprofile_full (nolock) where manager is not null
-- When they're getting staged during the import, you should see entries like this in the ULS logs:
w3wp.exe (APP1:0x4A5C) 0x4B94 SharePoint Portal Server User Profiles aj3b9 Verbose UserProfile.UpdateProfileImportStagingPersonProperty(): ready to write to staging: PartitionID '0c37852b-34d0-418e-91c6-2ac25af4be5b', RecordId '7871' , ProfileType 'User', Property 'Manager' , Value 'contoso_Manager1__653981c2-2454-4fb4-b862-420a9bae387b' 5841ce9d-9a86-9073-bbda-b799c29ac26b
w3wp.exe (APP1:0x4A5C) 0x4B94 SharePoint Portal Server User Profiles ogvr High User profile record of "contoso\userA" was changed by "contoso\farmAccount". 5841ce9d-9a86-9073-bbda-b799c29ac26b
-- In the above ULS example, the user being updated (UserA) has record ID 7871 in the upa.UserProfile_Full table, and his manager value is getting set to "contoso\Manager1"
10. If you suspect a problem with the post-processing, it’s best to look at the SharePoint ULS logs. The post-import processing is also done by the AD Import timer job. You can use the following PowerShell to show timer job history for the AD Import timer job. This can be helpful to see which server you need to get ULS logs from after you run an import:
$tjs = Get-SPTimerJob | ? {$_.name -match "_UserProfileADImportJob"}
foreach ($tj in $tjs)
{$tj.name
$tj.displayname
$tj.historyentries | select StartTime, EndTime, ServerName, status -first 10 | sort -Descending starttime}
-- This is what the post-import processing looks like in the ULS logs:
Note:
IMPORTEXPORT_PostImportUserProperties is for manager updates.
IMPORTEXPORT_PostImportMembers is for group membership updates, which are “staged” in the same way as manager updates and also part of the post-import processing.
OWSTIMER.EXE (0x0EBC) 0x17E8 SharePoint Portal Server User Profiles aei64 Medium UserProfileADImportJob: Begin executing. fc43cc9d-4014-e088-a10e-ef4c179a74fb
OWSTIMER.EXE (0x0EBC) 0x17E8 SharePoint Portal Server User Profiles afoeg Medium UserProfileApplication.SynchronizationPostProcessing: About to call IMPORTEXPORT_PostImportUserProperties fc43cc9d-4014-e088-a10e-ef4c179a74fb
OWSTIMER.EXE (0x0EBC) 0x17E8 SharePoint Server Database tzkv Verbose SqlCommand: ' [upa].[ImportExport_PostImportUserProperties] ' CommandType: StoredProcedure CommandTimeout: 0 Parameter: '@correlationId' Type: UniqueIdentifier Size: 0 Direction: Input Value: '00000000-0000-0000-0000-000000000000' fc43cc9d-4014-e088-a10e-ef4c179a74fb
OWSTIMER.EXE (0x0EBC) 0x17E8 SharePoint Portal Server User Profiles afoeh Medium UserProfileApplication.SynchronizationPostProcessing: Returned from IMPORTEXPORT_PostImportUserProperties fc43cc9d-4014-e088-a10e-ef4c179a74fb
OWSTIMER.EXE (0x0EBC) 0x17E8 SharePoint Portal Server User Profiles afoei Medium UserProfileApplication.SynchronizationPostProcessing: About to call IMPORTEXPORT_PostImportMembers fc43cc9d-4014-e088-a10e-ef4c179a74fb
OWSTIMER.EXE (0x0EBC) 0x17E8 SharePoint Server Database tzkv Verbose SqlCommand: ' [upa].[ImportExport_PostImportMembers] ' CommandType: StoredProcedure CommandTimeout: 0 Parameter: '@correlationId' Type: UniqueIdentifier Size: 0 Direction: Input Value: '00000000-0000-0000-0000-000000000000' fc43cc9d-4014-e088-a10e-ef4c179a74fb
OWSTIMER.EXE (0x0EBC) 0x17E8 SharePoint Portal Server User Profiles afoej Medium UserProfileApplication.SynchronizationPostProcessing: Returned from IMPORTEXPORT_PostImportMembers fc43cc9d-4014-e088-a10e-ef4c179a74fb
OWSTIMER.EXE (0x0EBC) 0x17E8 SharePoint Portal Server User Profiles aei66 Medium UserProfileADImportJob: End executing. fc43cc9d-4014-e088-a10e-ef4c179a74fb
11. If the manager updates are staged and processed successfully, then you should have the proper manager values now. The only issue I know of where the post-import processing succeeds, but you still don’t have the correct manager values is the manager - assistant swap issue I covered in this post:
https://blogs.technet.microsoft.com/spjr/2017/07/17/sharepoint-2013-2016-manager-and-assistant-values-swapped-in-user-profiles/