Securely Delegating IIS7 Settings in Hosted Environments

Classic ASP 

We tightened Classic ASP security a little bit more in IIS 7.0. The scriptErrorSentToBrowser property is set to false for example. This means that no script error whatsoever is displayed. In a hosted environment this might be a problem however. There are pretty much no other ways to troubleshoot Classic ASP errors. I wouldn't recommend to delegate the <asp> section because there are certain settings like the location of the template cache and the runOnEndAnonymously setting that hosters might not want to delegate. But there is help:

Here is an example how to delegate the scriptErrorSentToBrowser setting without delegating the complete <asp> section.  

1) Allow the delegation of the <asp> section in applicationhost.config via overrideModeDefault:  
<section name="asp" overrideModeDefault="Allow" />

2) Use lockAllAttributesExcept and lockElements to only allow the delegation of the scriptErrorSentToBrowser setting:
<asp lockAllAttributesExcept="scriptErrorSentToBrowser" lockElements="limits,cache" /> 

3) Now you as the hoster can use appcmd to set the scriptErrorSentToBrowser setting to true (see example below)
%windir%\system32\inetsrv\appcmd set config "Default Web Site" -section:asp -scriptErrorSentToBrowser:true

or you ask your customers to put the following statement in their web.config files:
<system.webServer>
   <asp scriptErrorSentToBrowser="true"/>
</system.webServer>

httpErrors 

And while we are at it: you can do the same for the httpErrors section if your customers wants to show Detailed Errors for remote clients, for example for troubleshooting purposes. Lock all attributes except errorMode (lockAllAttributesExcept="errorMode") and lock the error element (lockElements="error"). Now your customers can change errorMode from "detailedLocalOnly" to "Detailed" and they would get Detailed Errors for all of their errors. More on httpErrors here.