If you’re using an External FIM deployment to push your user profile information to SharePoint 2013, you probably want to take a read through this blog post. One of my customers reported an issue when they were doing this. All was well, except the manager field wasn’t getting populated, even though FIM was synching it. After a serious amount of troubleshooting, help from my colleague Joe Rodgers and a very dedicated FIM engineer, we solved this one. If you’re running into a similar issue, here’s what you need to look for. Open your ULS log, and look for an entry that looks like this.
02/05/2015 09:45:00.60 OWSTIMER.EXE (0x103C) 0x17FC SharePoint Portal Server User Profiles b3w8 High User Profile Application: SynchronizeMIIS encounters an exception: System.NullReferenceException: Object reference not set to an instance of an object. at Microsoft.Office.Server.UserProfiles.UserProfileImportJob.<>c__DisplayClass2.<IsTimerJobRunning>b__1() at Microsoft.SharePoint.SPSecurity.<>c__DisplayClass5.<RunWithElevatedPrivileges>b__3() at Microsoft.SharePoint.Utilities.SecurityContext.RunAsProcess(CodeToRunElevated secureCode) at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(WaitCallback secureCode, Object param) at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(CodeToRunElevated secureCode) at Microsoft.Office.Server.UserProfiles.UserProfileImportJob.IsTimerJobRunning(UserProfileApplicationJob timerJob) at Microsoft.Office.Server.Administration.UserProfileApplication.SynchronizeMIIS() at Microsoft.Office.Server.Administration.ILMProfileSynchronizationJob.Execute() 74c9e69c-86aa-0024-66e2-6b310fac0d26
What this means is that we’re getting a null reference exception, when the FIM management agent/connector for SharePoint finishes up. It calls a finalize method that’s part of the web service (http://sp:27741/_vti_bin/ProfileImportExportService.asmx:FinalizeProfileImportExportProcess ) that the FIM MA for SP uses. This finalize method is checking for a running instance of the User Profile ADImport Timer Job. The problem is that this timer job only gets created if your UPSA is set to use the “Active Directory Import” setting. If you never use/set that setting, which you probably don’t because you’re trying to use your External FIM deployment, the Timer Job will never exist. To create the timer job, all you need to do is change the setting in your UPSA’s “Configure Synchronization Settings” page to “Active Directory Import” and then to External FIM. This won’t break anything. You can also leverage the following PowerShell.
$upsa = Get-SPServiceApplication -name "YOUR_UPSA_NAME"
$upsa.NoILMUsed = $true
$upsa.NoILMUsed = $false
Once this is done, after you run your next sync, the Finalize method will run, and kick off what it needs to. It may take a few minutes, so be patient. To confirm the finalize method has run, you can examine your user profiles to ensure the manager field is now present, and also look for entries similar to this in the ULS logs.
02/12/2015 15:50:00.50 OWSTIMER.EXE (0x1230) 0x130C SharePoint Portal Server User Profiles afoeg Medium UserProfileApplication.SynchronizationPostProcessing: About to call IMPORTEXPORT_PostImportUserProperties 1f1fe99c-4693-0024-66e2-6d9812121bec
02/12/2015 15:50:00.50 OWSTIMER.EXE (0x1230) 0x130C SharePoint Portal Server User Profiles afoeh Medium UserProfileApplication.SynchronizationPostProcessing: Returned from IMPORTEXPORT_PostImportUserProperties 1f1fe99c-4693-0024-66e2-6d9812121bec
02/12/2015 15:50:00.50 OWSTIMER.EXE (0x1230) 0x130C SharePoint Portal Server User Profiles afoei Medium UserProfileApplication.SynchronizationPostProcessing: About to call IMPORTEXPORT_PostImportMembers 1f1fe99c-4693-0024-66e2-6d9812121bec
02/12/2015 15:50:00.50 OWSTIMER.EXE (0x1230) 0x130C SharePoint Portal Server User Profiles afoej Medium UserProfileApplication.SynchronizationPostProcessing: Returned from IMPORTEXPORT_PostImportMembers 1f1fe99c-4693-0024-66e2-6d9812121bec