There have been 2 instances now where the Script checkbox under "IIS > Sites > Site > Handler Mappings > Edit Feature Permissions" has become unchecked. What could possibly be causing this to occur? Haven't been able to find any information online about others experiencing this problem.

This could just be a coincidence but I just realized that this has happened twice now within a day or so of posting a full update to the folder which the site points to. Usually we upload a new folder of code, rename folders and the new folder takes the place of the old folder. The permission does not immediately uncheck, it is hours later. Is there any reasonable explanation why this might cause the script permission to disable automatically?


Might be an idea to keep an eye on the configuration history for IIS. For IIS 7 / 7.5, by default it'll keep track of configuration changes in c:\inetpub\history where there should be a snapshot folder per change detected. Although keep in mind that this is limited usually to the last 10 changes, although it can be increased by changing a setting. (I've actually got a powershell script that uses the snapshots in combination with Mercurial to have a complete history)

Comparing these files, at least you'll get a good idea of the exact time of the change. Then it might be worth checking the Security event log to see if anyone logged into the server before that time. Apart from that, check any Windows Tasks that are scheduled on the server. Haven't see anything like it happen on my servers so far.

  • No luck there. There is not actually a folder for anything changing in the last couple weeks. The change this morning to fix the option did not generate a snapshot either. – dmr83457 Oct 21 '11 at 15:07

Not really. Unless the web.config file being uploaded makes the change, it shouldn't just magically change.

Enable configuration auditing by opening out the Event Logs, finding the Microsoft\IIS-Configuration\Operations event log, and right-click enabling it.


If a change gets made to Applicationhost.config, you should see it there. If a change is made to web.config in the content folder, a) a simple diff will tell you what, and b) if the above system doesn't, file system auditing will be able to tell you who's changing it.

Finding out where it's happening is probably half the battle... then, you set your trap...

  • Oh, and the web.config change fits with it not being recorded in the configuration history - web.config, despite containing settings now, is considered part of the content. – TristanK Oct 28 '11 at 4:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.