BillS IIS Blog : ASP

More Tips and Troubleshooting Help for Classic ASP Developers

bills — Fri, 20 Feb 2009 23:10:18 GMT

Back in May of 2007 I posted a tips for Classic ASP developers post which has since received more than 50 comments and 85,000 views. Robert McMurray just posted a set of fabulous tutorials for Classic ASP developers. If you’re out there and having issues with Classic ASP and IIS7 and need some help, you’re not alone! Read these articles to get help:

Classic ASP is not installed by default on IIS 7.0 and IIS 7.5

In IIS 7.0 and 7.5, the classic version of ASP is not installed by default. Because of this, you might see HTTP 404 errors when you try to browse to an ASP page on your server, or you might see the source code for your ASP page displayed in your browser window ...

Using Classic ASP with Microsoft Access Databases on IIS 7.0 and IIS 7.5

Note: Microsoft Access databases have been popular for many years with developers who use Active Server Pages (ASP) for small-scale applications, but Microsoft Access databases are not designed for scalability, therefore Access databases should only be used ...

Classic ASP script error messages are no longer shown in a Web browser by default

In earlier versions of IIS, error messages from classic ASP scripts were sent to a Web browser, by default. Because these error messages might reveal sensitive information to malicious users, IIS 7.0 disables this feature by default. When your classic ASP ...

Using Failed Request Tracing to troubleshoot Classic ASP errors

One of the great troubleshooting features that is built in to IIS 7.0 is Failed Request Tracing, which lets you configure tracing rules on your server that will create detailed troubleshooting log files for custom failure conditions that you define. For example ...

Classic ASP parent paths are disabled by default

Classic ASP Parent Paths let developers use relative addresses that contain ".." in the paths to files or folders. For example, the following code excerpt illustrates an ASP page that maps a parent path: % Response.Write Server.MapPath("../example.asp")%> ...

APPL_PHYSICAL_PATH Server Variable on Windows Vista RTM

The original release of IIS 7.0 that shipped with Windows Vista returned a different value for the APPL_PHYSICAL_PATH server variable than that which was returned by previous

Tip / Trick: how to turn off "verify file exists" in IIS7

bills — Fri, 25 May 2007 15:37:57 GMT

I've seen several posts asking the question: how do I turn off the "verify file exists" setting on handlers / script maps in IIS7. I must admit, this seems to not be as straightforward as it should be. Hopefully this post helps you out.

The configuration setting for this feature is stored in the <handlers> section for each handler mapping, and is known as the resourceType attribute. For example:

For the ASP script map, we set resourceType="File" by default, so that the ASP engine won't get invoked for requests that are not mapped to real files. If you want your handler to be invoked for requests, even if there is no file or directory behind the request, set the resourceType="Unspecified". The allowable values for resourceType are "File", "Directory", "Either", or "Unspecified".

You can set this value in the administration tool by doing the following:

Step 1 - double click on handler mapping in the <handlers> feature:

Step 2: uncheck checkbox to set the handler to 'unspecified':

hope this makes life a little easier. ;)

Tips for Classic ASP developers on IIS7

bills — Tue, 22 May 2007 00:11:00 GMT

I was reminded the other day just how many classic ASP applications and developers there are out there! The original ASP rocks, I remember experiencing it for the first time back in 1996/97 when it first came out with IIS3, and being amazed at how programmable it was compared to ColdFusion. I built many an application using Classic ASP, and there will always be a soft spot in my heart for it. :)

There are a few changes in IIS7 which Classic ASP developers should be aware of.

ASP not installed by default

First things first! If you're moving from XP to Windows Vista / Longhorn Server, you may be getting this error:

--------------------------------------------------------------------------------------------------------------------

HTTP Error 404.3 - Not Found

Description: The page you are requesting cannot be served because of the Multipurpose Internet Mail Extensions (MIME) map policy that is configured on the Web server. The page you requested has a file name extension that is not recognized, and is not allowed.

--------------------------------------------------------------------------------------------------------------------

this is usually the case when you haven't installed the ASP component. Go to where you installed IIS and look under IIS/WWW Services/Application Development/ASP and install it. :)

Access and Classic ASP

A lot of people use Access as a database - because it is small, can be copied around, and is easy to manage. One of the changes we made in IIS7 in Vista broke using ASP and Access by default. I described this change in more detail in this post, but essentially it has to do with the fact that Application Pools now use the Application Pool identity's profile and temporary directory, rather than \windows\temp by default. And since the only one that can write to Network Service's temp directory is the Network Service, anonymous or authenticated ASP applications break, since ASP uses the impersonated identity to access the database. If you use ASP and Access on IIS7, you've probably seen this error, or a variation of it:

--------------------------------------------------------------------------------------------------------------------

Microsoft JET Database Engine error '80004005'
Unspecified error

--------------------------------------------------------------------------------------------------------------------

The answer is pretty straight forward: turn off loadUserProfile, or ACL the temp directory to allow writes. As a result of this and other compatibility issues, we're considering reverting this change in Longhorn Server / Vista SP1. In the mean time, you can work around it by doing either of the following:

This appcmd command will turn off loadUserProfile for the Default Application Pool. if your application runs in a different AppPool, make the corresponding change:

%windir%\system32\inetsrv\appcmd set config /section:applicationPools /[name='DefaultAppPool'].processModel.loadUserProfile:false

This command will ACL the Network Service temp directory to allow creator write / read privledges. If you run your Application Pool under a different identity, you'll need to ACL that owner's temp directory:

icacls %windir%\serviceprofiles\networkservice\AppData\Local\Temp /grant Users:(CI)(S,WD,AD,X)

icacls %windir%\serviceprofiles\networkservice\AppData\Local\Temp /grant "CREATOR OWNER":(OI)(CI)(IO)(F)

**Update 2/19/2009** if you are having issues with Access and ASP you might want to read this terrific guide recently posted on IIS.NET: http://learn.iis.net/page.aspx/563/using-classic-asp-with-microsoft-access-databases-on-iis-70-and-iis-75/

Script errors no longer shown in browser by default

As a result of our security paranoia, we turned off ASP's default behavior of sending script errors (including line number and code snippet to the browser. So instead of seeing the typical error you would see ASP throw, you will now see this:

--------------------------------------------------------------------------------------------------------------------

An error occurred on the server when processing the URL. Please contact the system administrator

--------------------------------------------------------------------------------------------------------------------

To revert back to IIS6- behavior, simply run the following command:

%windir%\system32\inetsrv\appcmd set config -section:asp -scriptErrorSentToBrowser:true

Or you can find it in the UI here:

then you'll be back to seeing this style of error instead:

--------------------------------------------------------------------------------------------------------------------

Microsoft VBScript compilation error '800a03ea'

Syntax error

/test.asp, line 4

Response.Write("I love classic ASP" && foo)
-------------------------------------^

--------------------------------------------------------------------------------------------------------------------

Parents paths disabled by default (redux)

We disabled parent paths by default with IIS6, but I've seen this hit people on Vista coming from XP, where it is still enabled by default in IIS5.1 The enableParentPaths setting determines where ASP "includes" should be allowed to escape the parent directory (eg. ../../../includeFile.inc). You'll see this error by default if you try to escape the current directory:

--------------------------------------------------------------------------------------------------------------------

Active Server Pages error 'ASP 0131'

Disallowed Parent Path

/test.asp, line 1

The Include file '../bad.inc' cannot contain '..' to indicate the parent directory.

--------------------------------------------------------------------------------------------------------------------

or you may see this error if you are using a path with ../ in it and your ADODB code

--------------------------------------------------------------------------------------------------------------------

Server.MapPath() error 'ASP 0175 : 80004005'

Disallowed Path Characters

/testdir/test.asp, line 9

The '..' characters are not allowed in the Path parameter for the MapPath method.

--------------------------------------------------------------------------------------------------------------------

To revert back to IIS 5.x behavior, simply run the following command:

%windir%\system32\inetsrv\appcmd set config -section:asp -enableParentPaths:true

or you can find the UI setting here:

APPL_PHYSICAL_PATH no longer returns "\" with path

If you use Request.ServerVariables("APPL_PHYSICAL_PATH") to get at the physical path for your application, you may notice that the physical path no longer returns with a trailing slash. In previous releases of IIS, we returned this value as stored in the metabase. In IIS7, we calculate this value based on the configuration store, and we never return a trailing slash. You'll need to account for this especially if you are the return value with some other part of the path in your application.

Session_OnEnd not firing

If you find that Session_onEnd event in your global.asa is not firing, check out this blog post from Lou on the issue and the fix.

Summary

I browsed through the IIS7 Classic ASP Forums, and these tips seemed to cover nearly all of the issues people were having. if you are having a problem with ASP on IIS7, check out the forums or leave a comment for me here. If I find the answer, I'll add it to this post! Thanks!