IIS error after install of current build.

Thona · Post by **Thona** » Sat Jun 07, 2008 3:14 pm

System: Windows Server 2008 Standard, 64 bit.

I can not open the admin page, i get the following error:

The current identity (DELETED) does not have write access to 'C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files'.

This is a funny error (and IMHO points towards a configuration error deeply in the setup code). I have set it up to impersonate a domain user account (whose identity I have deleted).

How am I supposed to fix that?

lbauer · Post by **lbauer** » Sun Jun 08, 2008 12:58 pm

Check to see if your domain account has read/write access to 'C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files'. If not, give the account the proper access.

The installer assumes the credentials of the logged-in user and tries to set the proper permissions on the file system. Sometimes this doesn't work, especially if the logged in user doesn't have Admin or Domain Admin privileges.

Thona · Post by **Thona** » Sun Jun 08, 2008 3:12 pm

Check to see if your domain account has read/write access to 'C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files'. If not, give the account the proper access.

Why? Sorry, but I work on a hosting control panel as a project so I fully investigated this.

The IIS 7 model is set up so that with PROPER configuration you do not have to set ANY permissions - the IIS_IUSR "permission set" is mixed into the token of the AppDomain.

I can see that you (for whatever reason) Vauls insists on running the AppDomain not under the user account, but under the system, then using impersonation to force a change to the user account.

This is 100% against the MS guidelines for IIS 7 domain account setup. The guidelines say that you should let the AppDomain run under the domain account, then NOT use impersonation. The AppDomain accounts gets proper permissions automatically mixed in, not through group membership but manipulations o the security token.

This is properly documented in the MS white papers, for example at:
http://learn.iis.net/page.aspx/118/samp ... re-i/rev/3

The installer assumes the credentials of the logged-in user and tries to set the proper permissions on the file system.

Which, under IIS 7, he should not have to do, at least not as far as we are talking getting IIS working. I run a hosting operation on the site, and there we follow the guidelines:
* Domain accounts are just set up (i.e. no special group membership)
* The AppDomain is set up to use the Domain Account. Windows / IIS 7 handles the proper permissions under the hood, without changing group memberships.
* Impersonation is not necessary, as the "base" identity on an appdomain is - the account the appdomain runs under.

I wish there would be a proper documentation for SourceGear IIS setup (and support for doing so without running the installer).

Thona · Post by **Thona** » Mon Jun 09, 2008 11:58 am

After making the changes as I outlined (i.e. turn Imperonation off, put application puool identity to the domain account used also by the database)...

...the service works without any changes in security. Now, if I only would get a way to make database updates without an isntaller this thing would really work from hosting