Unfortunately I don't have a whole lot of information on this.
I have a customer who has moved their site from an ancient system to IIS7 on Windows 2008 Server. Info about the error is below:
Error:
E:\wwwroot\sp\xxx\online_data.xls
Microsoft VBScript runtime error '800a0046'
Permission denied
/xxx/oat/exceldata.asp, line 52
Code:
49 response.write(server.mappath("online_data.xls"))
50
51 set fso = createobject("scripting.filesystemobject")
52 Set act = fso.CreateTextFile(server.mappath("online_data.xls"), true)
The only suggestion so far is to:
grant the application pool
(DefaultAppPool / Classic AppPool)’s
impersonated identity read and write
permission to the physical folder
which the asp page reside
Will look at this when I get access, but other suggestions would be appreciated.
The provided answer is correct, but I needed a little more detail on how to accomplish it. To make it really easy, follow the steps below. I was setting up an asp page counter on a sandbox system in our intranet.
- Open Computer Management.
- Drill down to the IIS server
Management
- In the Connections pane, click on
Application Pools
- In the Application Pools pane,
right-click on DefaultAppPool and
choose Advanced Settings. Look in
the Process Model section.
- By default, the Identity property is
set to ApplicationPoolIdentity.
This is a built-in account.
- If it's set to the default, then you
can use the built-in user
machinename\IUSR for your
permissions settings. I had to
specify the machine name because
this is a virtualized server, YMMV.
- If it's not set to the default, use
that username for your permissions
settings.
- Cancel out of the dialog and return
to Windows Explorer, to the folder
where you need to add permission.
- Right-click to get Permission
settings.
- Set up machinename\IUSR or the
non-default username you determined
in steps 6/7 above. Grant
permissions as needed.
This helped:
http://learn.iis.net/page.aspx/140/understanding-built-in-user-and-group-accounts-in-iis-7/
The suggestion is correct. If the path to the solution is not immediately obvious for whatever configuration reasons, try running procmon (filter on "online_data.xls") and see who's failing, why, and what user account they run under. Then check the ACLs.
I had a similar problem in Windows 7 and my solution was changing the Authentication. From IIS, select the site, go to Authentication, disable Anonymous Authentication and enable Windows Authentication.
Spent a bit of time with something similar. Even with the correct settings it wasn't working.
I then tried create the actual file first on the server. Turned out to be the trick that worked. Now my ASP page writes to the existing file no problem.
Must be something about creating a new doc from scratch that is another issue.