IIS Shared config - applicationHost.config Error: Cannot write configuration file due to insufficient permissions

Question

I've setup a UNC share for IIS shared config using a specific AD service account and set to FULL CONTROL. I've also exported the config from one IIS server and set-up an additional IIS server to point to the share. When I open the applicationhost.config for example on the UNC share and remove an application pool, I can see the entry also remove in both IIS servers.

So I know:

1) I can export to the share with the specific service account

2) Both IIS servers can read the config when I edit manually

3) However when I remove an app pool from one of the IIS servers through the manager I get the above error.

I've tried using the process monitor utility to see what account is being used to write to the config and it seems it is my own AD user account rather than the shared service account. I know IIS Manager has my username eg ROOT\\MYNAME logged on, but I wouldn't have thought it would use this to write changes to the shared config. Surely it would use the service account?

Does anyone know how to prevent this error? Why does the shared config and tied service account not come into play when making changes on one of the servers?

Answer 1

So, IMHO, this error is a red herring. I was publishing to a server and got a message saying I was out of space. So, I logged in, realized there was a bit of cruft in extra apps published in IIS, we didn't need. I right clicked and tried to remove one. I got the same error as you.

Having done some manual changes to applicationHost, I thought it "might be me" but it seemed very odd that editing this file would cause such a thing. However, I had recently learned that windows does some funky 32 vs 64bit machinations with this file (google it).

Deciding I had better things to do, I asked our IT to add space to the VM and guess what? I am no able to remove these apps. My guess is that I was at the end of the line on space and the backend management of these special files was not completing and throwing this not-so-helpful exception.

I'm not a 100% about this. For full disclosure, I will add that updates had been applied recently, but I'm pretty confident that this is a possible solution.