Here's another in what seems like a growing list of permissions gotchas in SharePoint 2010. Assume if you will, you are a crack developer and building a custom application for SharePoint 2010. You're writing code on your development server, which has a FULLY functioning installation of SharePoint 2010. You want to work with some user profile data, so you create an instance of the UserProfileConfigManager. Strangely, when you do this you get an exception that says "No User Profile Application available to service the request. Contact your farm administrator."
Hmm, seems strange. You double check your settings, your user profile service application is up and running. You're probably a farm admin even in this scenario and you are able to manage it - so what is the scoop? You may think, ah, I need to grant myself rights to manage the application. We've seen that behavior in another posting I published just today on working with FAST user contexts. So you find your user profile service app, click on the Administrators button in the ribbon and give your self Full Control rights to it. You try again - same problem. Grrr! Yes, this can get frustrating. As it turns out, there is yet another place where you may need to set permissions, and this is one of those cases. If you look in the ribbon when you select a service application, you will see the Administrators button, but there is also the Permissions button on the far right. In this case, click the Permissions button. Add your account and give it Full Control rights. NOW, go back and try your code again - this time it should work.
Sorry, I wanted to add one other scenario I have seen happen. Many times you create the ServiceContext for getting the UserProfileManager by getting a reference to an SPSite and then using the SPServiceContext.GetContext method. What I have seen happen before is that if that site that you create the SPSite reference to allows anonymous access, you may still get this error. When disabling anonymous access at the site collection level it started working. Just another FYI.