Home/ Questions/Q 849781
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T07:09:28+00:00

at work I am struggling a bit with the following situation: We have a

  • 0

at work I am struggling a bit with the following situation:
We have a web application that runs on a WIndows Server 2008 64 bits machine. The app’s ApplicationPool is running under the ApplicationPoolIdentity and configured for .net 2 and Classic pipeline mode.

This works fine up to the moment that XmlSerialization requires creation of Serializer assemblies where MEF is being used to create a collection of knowntypes.

To remedy this I was hoping that granting the ApplicationPoolIdentity rights to the ASP.Net Temporary Files directory would be enough, but alas…

What I did was the run the following command from a cmd prompt:

icacls "c:\windows\microsoft.net\framework64\v2.0.50727\Temporary ASP.NET Files" /grant "IIS AppPool\MyAppPool":(M)

Obviously this did not work, otherwise you would not be reading this 🙂

Strange thing is that whenever I grant the Users or even more specific, the Authenticated Users Group those permissions, it works. What’s weird as well (in my eyes) is that before I started granting access the ApplicationPoolIdentity was already a member of IIS_IUSRS which does have Modify rights for the temporary asp files directory.

And now I’m left wondering why this situation requires Modify rights for the Authenticated Users group. I thought it could be because the apppool account was missing additional rights (googling for this returned some results, so I tried those), but granting the ApplicationPoolIdentity modification rights to the Windows\Temp directory and/or the application directory itself did not fix it.

For now we have a workaround, but I hate that I don’t know what is exactly going on here, so I was hoping any of you guys could shed some light on this.

Thanx in advance!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    If the application pool is running as AppPool Identity then things should work out-of-the box since the worker process will be injected the IIS_IUSRS SID which will have the right permissions to write.

    My guess, is that the application must be using Windows authentication and impersonation is enabled in ASP.NET so that code is probably be ran as the specific user that is making the request and not necesarilly the process identity.

    Am I right on the guess that the app is running Windows Authentication? and impersonation is enabled in asp.net ?

    • 0