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)
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.
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!
Share this post: email it! | bookmark it! | digg it! | reddit! | kick it! | live it!
Comments