IIS7/Win7 - Make sure that the application pool identity has Read access to the physical path

Question

I am running a localhost instance (so domains are not my issue!) on my laptop utilizing Win7 and IIS7. I am getting authentication errors on my website and my one virtual directory.

default website - localhost:80  c:\mydirectory\localhost
virtual directory - c:\mydirectory\weborb30

Please notice these are not under c:\inetpub\wwwroot!

Now, I did some googling/binging and discovered that I needed to add my [machinename$] to the ACLs. (Hope I said that right.) I did that, even though it is a domain thing. Nothing changed. I further read that IIS7 is now using ApplicationPoolIdentity and I tried finding that on my local machine - no luck there. So, I changed the App Pool to run under another built in account. Now, not only do I get the Authentication error I can no longer AttachProcess to W3WP.

How the heck do you PROPERLY setup VS2005, IIS7 on a WIN7 box to run locally???

Answer 1

I was having a similar problem and ended up fixing it by giving read permissions to the "IUSR" user and "IIS_IUSRS" group.

I'm not really sure why this works. It seems odd needing to give permissions to IUSR when I thought it would have been included in the IIS_IUSRS group. I think part of it relates to the account the application pool runs as (e.g. "IIS AppPool\Classic .NET AppPool" for a classic .NET application pool in IIS 7.5 / Windows 7), but I'm still unclear.

This StackOverflow question seems to be related.

Answer 2

Before you made changes to the app pools, all you probably needed to do was add read access to your physical directory for the "network service" account (that is the default account used by asp.net on vista & win7).

I think what you may be looking for at this point is this:

aspnet_regiis -ga <useraccount> 

The -ga switch tells aspnet_regiis to configure all the security for asp.net. Usually you only need to do this stuff when you are using impersonation in your application, but if you are changing the default user for the application pools then you are effectivly doing the same thing IIS wide.

The best complete documentation I've found is on MSDN. It applies to the previous version of IIS, IIS 6, but it is pretty easy to apply it in IIS 7 environments