Failed to start monitoring changes on global.asax .net 3.5 Web service using Impersonation

Question

I am trying to use impersonation in a an asp.net 3.5 webservice. However whenever I try to run the service with Impersonation enabled (In web.config) I am receiving the following error in my Windows Event log:

Exception message: Failed to start monitoring changes to 'C:\1work\temp\NotificationWatcherWebServiceClean2010\NotificationWatcherWebService\NotificationWatcherWebService\global.asax'

I initially didn't even have a global.asax so I tried adding 1 and adding explicit permissions for the user I'm trying to impersonate.

I am using the following environment.
Visual Studio 2010
Windows 7 64-bit
.Net Framework 3.5

Any ideas?

Bermudez

Try add 'Everyone' to prove that it is a file permission issue. I very much doubt that the user you are impersonating is the one that ASP.Net is running as. – Interregnum

Adjusting the permissions didn't work for me, but if I run Visual Studio as the Administrator user, it gets around the error. – Misogamy

Answer 1

I've seen this issue each time I get a new box, or have mine reimaged. What I have to do is grant the account that is being impersonated (assuming it's a single account, otherwise you may need to grant a group of users) access to key folders.

Specifically C:\windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files but also you might try c:\windows\temp and your own user temp folder located at C:\Users\userid\AppData\Local\Temp.

Haag

In my case (error occured during web project build) I needed to add the impersonation account to the project root directory. I gave the account Full Control but it may only be necessary to give it read or modify - I was in a rush. – Pelecypod

I really think this is a bug in how Microsoft designed the publishing flow from Visual Studio.. this many years later and I'm still getting an error like this. See my answer for a different workaround – Foldboat

Answer 2

It seems this error is a result of the impersonated user account not being a member of the IIS_IUSRS group. Adding membership to this group in Control Panel / Administrative Tools / Computer Management / Local Users and Groups should help to resolve the problem.

Imperfection

Answer 3

For development purposes, running Visual Studio as Admin might help.

Barricade

Answer 4

Please note if your folder is shared with some other user and inheriting parent permission then also, this issue arises.

We just have to remove that user (from the Security tab in the properties dialogue of the folder) and its parent permission mapping

Also,

• make sure that Visual Studio is running in Admin mode
• make sure that the folder in concern is not read only

• make sure that Authenticated Users or ASPNET and (optionally) IIS_IUSRS have access to the concerned folder

• clean the temp

Stalactite

Answer 5

This is so bad. I can't believe I'm encountering this on VS 2017 (15.9.15).

I am doing file path / UNC path style publishing to our production server.

The fix for me was to simply remove the impersonation from my web.Release.config transform file

Get rid of this in your system.web element:

<identity impersonate="true"  userName="CONSOTO\my_serviceacct" password="pwd123456" xdt:Transform="Insert"/>

This allows publishing to proceed as normal, then, I obviously have to put the impersonation back into place on the target installation server.

Funny thing is, web config transformations work just fine with impersonation included.. if I right-click the Web.config and select "Publish Web.config". The impersonation bit only seems to break when I publish the entire web site.

Foldboat