Description of the Problem
I am currently performing massive SharePoint 2013 deployment at one of my favorite XXL customer. While during the first deployments I did not experience any specific issue with UPS, the most recent ones all ended up with the same problem: the User Profile Service refused to start-up therefore leaving it in an non-useable state (but hopefully not stuck on starting:)).
Looking at the ULS logs revealed repeated entries similar to the one hereunder:
08-06-2013 15:12:29.19 OWSTIMER.EXE (0x1668) 0x183C SharePoint Portal Server User Profiles 9sip High UserProfileApplication.SynchronizeMIIS: Failed to configure MIIS post database, will attempt during next rerun. Exception: System.Runtime.InteropServices.SEHException (0x80004005): External component has thrown an exception. at Microsoft.Office.Server.UserProfiles.Synchronization.ILMPostSetupConfiguration.ConfigureMiisStage2() at Microsoft.Office.Server.Administration.UserProfileApplication.SetupSynchronizationService(ProfileSynchronizationServiceInstance profileSyncInstance).
As you can imagine, we’ve searched in all directions (permissions, service account privileges, possibly missing or corrupt components…) until we finally decided to open a call at MS Support.
Possible Cause(s) and Solution(s)
The support engineer quickly pointed us in 2 directions:
- IIS Application Pool Shutdown delay too shoot
- Custom PowerShell Profile
While the first one did not help, the second appeared to be the silver bullet: removing the custom PowerShell profile from the SharePoint server allowed the UPS to finally start and successfully performed its provisioning process.
Until now we could not isolate the exact root cause: was it the presence of a custom profile or was it something in the profile that lead to the problem but one thing is sure, to complete UPS provisioning, SharePoint 2013 needs the timer service to run a job that calls PowerShell commands or script and unfortunately, it may not compatible with custom PowerShell profiles. At least, you would expect the job to start PowerShell with the /noprofile parameter but it’s definitely not the case.
Kudos to my colleague Gert S for the troubleshooting! Happy UPS provisioning!