IIS Informant: Ensuring That All Your Web Sites Return Detailed ASP Error Messages

We recently added a few Web sites to our IIS 5.0 server, and we use Active Server Pages (ASP) on those sites. However, in the event of a 500-100 error, only the Default Web Site returns a detailed error message. How can we force the other Web sites to return detailed information?

I'm surprised that this question doesn't surface more often. The answer involves an obscure but interesting IIS detail. First, let me provide some background on the 500-100 error codes. The HTTP error codes are an Internet Engineering Task Force (IETF) Request for Comments (RFC) standard (http://www.w3.org/protocols/rfc2616/rfc2616-sec10.html) that defines error 500 as an Internal Server Error. Microsoft has added a series of subcodes for the 500-100 errors that the ASP processor returns when it encounters a problem rendering an ASP script. No RFC covers 500-100 errors. In this case, I'm grateful that Microsoft provides functionality beyond the requirements of the RFC.

A special .asp file, 500-100.asp, processes ASP errors. If you inspect the Custom Errors tab on the Default Web Site's Properties page, you can see how 500-100.asp is configured to process 500-100 ASP errors. In the listing of error codes, click the line for 500-100, then click Edit Properties to reach the Error Mapping Properties dialog box, which Figure 4 shows. You can see that when asp.dll returns a 500-100 error, the error goes to the relative URL /iisHelp/common/500-100.asp.

For this error-mapping process to work, you must have a directory named IISHelp on the Web site. When you install IIS, the installation process automatically creates a Default Web Site and places within it the IISHelp virtual directory, which is mapped to the location C:winnthelpiishelp. Thereafter, the 500-100.asp error-processing script at C:winnthelpiishelpcommon is available when ASP errors occur on the Default Web Site.

However, when you create a new Web site, by design, IIS doesn't create an IISHelp virtual directory for you. Without the virtual directory present, in the event of a 500-100 error, the WWW Service Master Properties return only the message Internal Server Error—ASP Error. Because new Web sites inherit the Master Properties, those sites won't return extended 500-100 error messages unless you configure them to do so.

One way you can configure your server so that all Web sites process 500-100.asp errors with the 500-100.asp script is to create a mapping in the Custom Errors page in the Master Properties for the WWW Service that matches the detail that Figure 4, page 9, shows. If you use this method, you must create a virtual directory named IISHelp for each Web site and map it to C:winnthelpiishelp. The virtual directory must be functionally identical to the IISHelp virtual directory configuration on the Default Web Site.

For a secure server configuration, you must relocate the error-processing files from the IISHelp folder and place them on a drive other than the system drive. Create a virtual directory that maps to the new location, and assign the 500-100 error to that virtual directory. For security reasons, your server should never have a virtual directory that maps to C:winnthelpiishelp because that location contains not only the error-processing files but also the online documentation for the server—which might link to server resources you need to protect. An attacker could access these resources with the URL http://servername/iishelp.

If creating an entry in the WWW Service Master Properties isn't suitable for your system site, you can enable 500-100.asp error processing on your system in several other ways, such as creating an administrative script to walk your Web sites and automatically add the IISHelp virtual directory.

Note that the IIS Lockdown tool can remove the IISHelp virtual directory from the Default Web Site, thereby disabling detailed ASP error handling, a fact that to my knowledge isn't documented.