>At 06h00 is the scheduled time for IIS to recycle the application pools. Each of them have four worker processes. At every 10 days, approximately, IIS will fail to load properly all four instances of the worker process resulting in Web site hits not being responded, if the hit is in regards to one of the failed restart of a worker process. This is something I mentioned before but I thought I would create another thread with updated information.
>
>From November 22nd, we have moved into a virtual environment. This is a VMWare environment.
>
>Everything is now under a NAS technology. The NAS hardware being used is from NetApp company. They use a V-Series controller. They use disk rack called Disk Shelves. The data protocol is FC at the physical layer.
>
>The Web server has its installation files on the C: drive. However, its Web site files reside on a NAS. So, once we enable the load balancer, we'll be ready to go.
>
>This is Windows Server 2008 SP1, with IIS 7.5 and .NET Framework 4.5. The DLL resides in the Bin directory so they are in-place compilation.
>
>For the Web site, I have one application pool having four worker processes.
>
>The first two times we had a problem, one and two worker processes never started at recycle. They were loaded in memory by IIS but hits forwarded to them were not able to be responded. This resulted as you know what. The user waited indefinitely for a hit that never got responded. The third time it happened, two worker processes responded partially until we found out after 2.5 hours that it was the case and an IISRestart was necessary and everything went ok that time.
>
>I know there aren't that many installations in such environment using Microsoft technology. But, this is what we have and we need to find how to resolve this. This is already reported that there are issue with IIS in virtual environment causing this reaction. I just do not know what has to be done to resolve it.
>
>And, this is just not our product. Another product, from another company, resides also in this environment, and they experience the same problem as us on occasional basis.
>
>Several installations of IIS were done so we have eliminated that from the loop. Knowing that the other product from another company has the same problem also leads us to think nothing is wrong with the code. The only difference in the code done after we moved into this new environment was to detect the application pool name. To be sure it was not related, I put that code in comment last week and we had the situation again this morning.
>
>This new environment and IIS do not co-exist very well. So, additionnally to the regular installation, something else seem to be necessary to be done to workaround that problem. Any input would be very appreciated. This is an issue that is very costly presently.

Nothing in logs ?