A couple things here.
When having problems with the backend accounts of IIS and their ability to
support ASP, take a pure HTML page, no serverside script in it, and make a
copy with a .asp extensiion. Then at cmd prompt run iisreset (not necessary
but it guarantees your test is starting with fresh IIS loadup). Then
navigate
directly to the html page that has the asp extension.
If it fails this says it is due to IIS ability to use the asp.dll rather
than something
the asp page you had been trying was doing in its script.
You will get the 500 error in either case, so this cuts the chase in half
either way.
The account mentioned IWAM_* will be used on access to an anonymous web
with ASP if you have it configured to use high isolation
In the IIS mgmt UI, in the properties of the web try switching it down to a
less
secure isolation setting.
IWAM_* will fail login if you have removed Authenticated Users and
Interactive
from the Users group. If you have done this you need to add the IWAM_* to
the Users group.
Since the message you get is not about login type denied, the above may or
may not be (part of) your issue.
IIS will manage a number of user rights that IWAM_* needs, so those should
be OK.
Also, in the properties of the website in the IIS mgmt UI check to make sure
that you are allowing IIS to manage passwords.
Now, if you had changed the pwd of the IWAM_* account in the user management
interface, then you will have to set the same password in the COM+ component
for the website (in component services) or uninstall/reinstall IIS.
In fact, if you save your content somewhere, use add/remove to uninstall
IIS,
delete the inetpub directory and the wywtem32\inetsrv directory (rather as
much
as you can), and then reinstall, the IIS installer will try its best to get
everything
right again. IIS and IWAM_* do not require DCOM, but some things that you
do in ASP can cause this dependency.