HOWTO: Debug IIS configuration changes that mysteriously disappear

I got this question a few days ago:

Question:

Hi David,

While perusing the internet to discover the cause of virtual directories disappearing from within IIS6.0, I found several of your posts like this one: <https://www.msusenet.com/history/topic.php/1869432174-1.html>, likely only posted once by yourself, but mirrored on other sites.

I too have a monitoring script on our servers here, wich fires an IISreset when a site in a particular application pool fails to respond, and then a second time 5 minutes later (only with the reboot switch), if it is still not responding.

I was hoping you might have some insight to share into:

1.) How to recover these lost virtual directories? (Do I simply recreate them?) and

2.) Suggestions/recommendations for improving the process by which we deal with unavailable sites, for instance, can we save the metabase config to disk from within script before an IISreset if the IIS process appears to have hung?

I hope you have the time to reply, and that this mail doesn't bug you too much! :)

Thank you

Answer:

1. Unfortunately, as soon as you kill inetinfo.exe before it has committed the configuration changes to disk, the changes are permanently lost. You will have to recreate them again and make sure they are persisted to disk.

2. The only way to deal with unavailable sites is to debug them to figure out WHY they are unavailable and fix them. If there is a bug in the web application, it will keep happening and IISRESET will not make it go away. There is also no guaranteed way to save metabase config if the IIS process appears to have hung -- a bad application could have hung inetinfo.exe such that there is no way to save metabase config.

Thus, relying on simply restarting IIS is NOT a solution, it is a bandaid while you fix the real problem. I suggest you start with a tool like IIS State ( https://www.iisfaq.com/default.aspx?view=P197 ) during the hang to figure out what inside of the IIS process is hanging (more than 90% of reported "IIS hangs" are actually caused by 3rd party or user applications, but most people just conveniently blame "IIS hangs" because they cannot figure out what is actually hanging. IIS State allows someone to independently debug and help determine what is going awry).

//David