Changing the Central Admin URL may affect some service applications (PowerPivot & User Profile)
Recently we decided to change the central admin URL to use SSL and a host header. There are several articles out there on the steps required to do this successfully. We followed the steps and were quickly up and running. If you have already created some service applications and have been using them you may run into issues with the URL change.
USER Profile Service Application
About two weeks after the URL change, we found out that the User Profile service was not working properly. When we loaded the MIISCLIENT.EXE (typically located at 'C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\UIShell' ) we saw the miisclient console shows 'stopped-extension-dll-exception' error. Basically the MIISCLIENT was pointing to the old Central Admin URL. To verify this
- Open MIISCLIENT.EXE
- Click on Tools, Management Agents (or click the Management Agents in the bar)
- Right-click on the management agent with type 'Extensible Connectivity' and select Properties
- In the Properties window, select "Configure Connection Information "The "Connect to:" beginning field should point to the new SharePoint Central Administration site. DO NOT CHANGE THE URL in MIISCLIENT.exe See https://support.microsoft.com/en-us/help/2517937/support-for-modifications-to-the-user-profile-configuration-settings-v
To fix simply log into Central admin and Stop and Start the User Profile Synchronization Service from the server. When the User Profile Synchronization Service re-provisions it will update the connection information within FIM. After stopping/starting the service you may go back into MIISCLIENT.EXE and verify that the URL is now correct.
PowerPivot Service Application
Even though we had already provisioned the PowerPivot service application we had not started to use the application. When we started to try and setup PowerPivot, we noticed the Health Analyzer Rule: 'PowerPivot: Usage data is not getting updated at the expected frequency' and The “PowerPivot Management Dashboard Processing Timer Job” was failing. Looking at PowerPivot mini-Dumps we noticed that a couple of PowerPivot Properties were point to the original URL.
Using PowerShell (Get-PowerPivotServiceApplication ) we identified the two properties of interest. UsageWorkbookUrl (Can be modified ) and ServiceAppFolderUrl (Read Only), both these properties had the old URL . We decided to put in Alternate Access Mapping for the old URL to the new URL and that did seem to fix the issue with the Report Management page load but we weren't comfortable that it would address everything, so since this was not in use yet and we were not in production, we decided to delete and recreate the service application.