IIS7 Permission Denied - ASP File Write

Question

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

Answer 1

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.

Answer 2

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.

Answer 3

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.

1. Open Computer Management.
2. Drill down to the IIS server Management
3. In the Connections pane, click on Application Pools
4. In the Application Pools pane, right-click on DefaultAppPool and choose Advanced Settings. Look in the Process Model section.
5. By default, the Identity property is set to ApplicationPoolIdentity. This is a built-in account.
6. 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.
7. If it's not set to the default, use that username for your permissions settings.
8. Cancel out of the dialog and return to Windows Explorer, to the folder where you need to add permission.
9. Right-click to get Permission settings.
10. 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/

Answer 4

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.