The scope of the feature is Web.

SPWeb site = (SPWeb)properties.Feature.Parent;
site.AllowUnsafeUpdates = true;

// Set the Web Application's default error page
SPSite siteCollection = new SPSite(site.Url);

SPWebApplication webApplication = siteCollection.WebApplication;
webApplication.FileNotFoundPage = "somepage.html";

site.AllowUnsafeUpdates = false;

When it hits the line webApplication.FileNotFoundPage = "somepage.html"; I get hit with Access Denied. This code is within a RunWithElevantedPrivileges delegate. If I run similar code from a console application from Visual Studio, it works fine.

How can I elevate privileges enough to update the web application settings? I've tried scoping it at Site and Web Application to try, and they didn't work.

3 Answers 3


You're seeing this because RunWithElevated runs the code under the AppPool account of the current web application, but the SPWebApplication itself is stored in the config database, which is handled by a different account (the farm account).

You will have to run this Feature at Farm scope in order for it to be able to write to the config database.

  • Good to know there is a solution to this! :-) May 26, 2011 at 22:28
  • Thanks for the clarification James. I knew there was some sort of issue like this, but I didn't know the details. Are the only options of modifying the SPWebApplication from a console app? What about a workflow then? I imagine not. May 27, 2011 at 13:19
  • Workflow would probably launch in another app identity again. If you run it as a console app, it'll use whatever context you're logged in as, and if you run as the Farm account, you should have no issues.
    – James Love
    May 27, 2011 at 13:43

James' answer is correct; this is because the SPWebApplication's properties are stored in the Config database, but the AppPool account doesn't have rights to that database. This is common in least privilege setups.

However, an alternative would be to grant access to the Config database to the AppPool account. This isn't a great idea - it does take you away from least privileges - but it could be suitable in your situation. Plenty of our customers seem to have configured their systems this way - I'd say it's more common than a least-privileges configuration.


I'm not sure that this can be done from within the scope of a Web application.

AFAIK your options are limited to a console application (as you have already found), a custom stsadm extension or PowerShell.

In the past we have followed this KB to specify a custom 404: http://support.microsoft.com/kb/941329

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.