User Profile Application Unavailable with UserProfileApplicationNotAvailableException
If you’ve ever had a problem with the user profile application (UPA) not working, this post is your checklist. It’s not the clearest problem to troubleshoot.
The error usual manifests as a “UserProfileApplicationNotAvailableException” exception, or in detail:
Failure retrieving application ID for User Profile Application Proxy '{name}': Microsoft.Office.Server.UserProfiles.UserProfileApplicationNotAvailableException: UserProfileApplicationNotAvailableException_Logging :: UserProfileApplicationProxy.ApplicationProperties ProfilePropertyCache does not have {guid} at Microsoft.Office.Server.Administration.UserProfileApplicationProxy.get_ApplicationProperties() at Microsoft.Office.Server.Administration.UserProfileApplicationProxy.get_AppID()
To be honest, this is one of the least clear errors the product-team have ever managed to raise so it tends to be confusing as so why it’s happening. I’m hoping to clarify why here.
What Might Break if the UPA Isn’t Working?
First of all, what might break assuming there’s no functioning UPA in the background? Several things.
- User profile service application administration page (obvious).
- My sites functionality – any part.
- Social functionality (built-in, not Yammer).
- PowerShell scripts that do anything with user-profiles.
- Web-parts or pages that use profile data at all.
User profiles can even work for everything except one area; PowerShell being the most common thing to fail. User profiles aren’t something directly accessed of course but rather used by something else – websites, PowerShell, audiences, etc.
Why Would UPA Calls Fail?
Actually only two reasons:
- Availability. There’s no servers to handle the user profile request.
- Security. The calling identity doesn’t have permissions to invoke the user profile service application.
Problem 1 is fairly simple to correct – start the “user profile service” in another server (that’s online). If your server(s) that handle user-profile service-requests are offline and there’s no more available, you’ll get the “UserProfileApplicationNotAvailableException” error too. More explained here.
Problem 2 is more complicated but confusingly the error thrown is the same as “no servers”, and then whatever code invoked the user profile app API call will fail.
Grant UPA Access to Necessary Processes
By default, SharePoint grants access to the UPA just the farm account, and not even the UPA application-pool user, which is a bit odd indeed as if these account differ (which they should) then certain functionality just won’t work out of the box.
Specifically, you’ll find in the social newsfeed, if you click “everyone” you’ll get an error & it look like the distributed cache is broken with SharePoint giving the message “there was a problem retrieving the latest activity. Please try again later”. Well, it turns out that’s probably permissions, and probably that your user-profile app-pool account doesn’t have permissions to the user profile application (strange but true).
But I digress, to grant permissions, click on the service application & click “permissions”:
From there, add the user & grant “full control”:
Important: permissions are “cached” “client-side” so in other words you’ll need to restart the process calling the UPA for it to work. I say “cached”; basically trying to get a UPA connection will automatically fail subsequent times if you had an ACL failure the 1st time.
What Accounts Need Permissions to the UPA?
Good question. Normally just the farm account, web-application account & user-profile account. But if you have PowerShell scripts, you’ll need to add the user which runs the PowerShell process too.
Basically, whatever the process identity of the calling code, will need permissions to the UPA.
Wrap-Up
Hopefully this has helped someone. It’s true it’s not so clear why the UPA fails sometimes, but this should help clarify what to check at least.
Cheers,
Sam Betts
Comments
- Anonymous
August 28, 2016
We ran into the same error but it was caused by some IIS Application Pools that were stopped after SharePoint Software Updates. Just had to start them again.