So there I was, creating a SharePoint 2010 Timer Job to retrieve and aggregate tag information from the Social Data Service. Using a pattern that worked well in SharePoint 2007, the feature receiver in the solution was tailored to save information for each execution of the job to the property bag of the web application.
But the timer job failed to register when activating this solution through the features admin page on the site. The event log showed an "Access denied" SecurityException error, occuring in the call to SPWebApplication.Update(). The code was simply attempting to set a web application property at that stage.
Time passes... Lots of experimentation and research.... Finally discovered the cause is related to applying least privileges access to accounts on the server install. The account under which the feature gets activated when clicking on "Activate" in the browser UI does not have sufficient rights to make changes in the configuration database. And web application property bag settings seem to be saved to the configuration database rather than to a content database (makes sense, I guess, as a web app can be associated with multiple content databases).
The solution therefore is to activate the feature using PowerShell whilst logged in with an account having update rights on the config database - for instance, using the setup account (which you used during installation, of course, didn't you?!)
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment