メイン コンテンツにスキップ

 Subscribe

If you are a web developer, you have most probably used the “quick-and-easy” iisreset command to reset a misbehaving IIS host. This trick usually works great on a classic Windows Server VM. However, if you are running your application on Windows Azure, please DO NOT run iisreset.

Well, if you are reading this post, there is a chance that you like going through all our blog posts, which is very cool and we hope you would find useful them while developing your next application on Microsoft Azure. So if you are one of them, I want to say a very big THANK YOU!

But if our blog posts are not your perfect idea of reader’s digest or bedtime reading, you are most likely here because you tried to reset IIS manually on your Microsoft Azure VM and now your website in unreachable. If that’s the case, don’t worry, you still have a quick and easy fix (but promise me, that you won’t run Reset IIS on your Microsoft Azure Web Role in the future).

Why shouldn’t I run IIS Reset on Azure?

When you run IIS Reset, one of the things that happens is that the Windows World Wide Web Publishing Service (W3SVC), the service responsible for connecting clients to your website, is stopped.

In classic Windows Server, the “Startup Type” of W3SVC is Automatic. Thus, the W3SVC service restarts automatically and everything works fine.

On Windows Azure, however, W3SVC is set to “demand start” so that the Windows Azure Agent that runs inside your Web Role can configure W3SVC before starting the role. Unlike IIS in classic Windows Server, an IIS role in Azure is not intended to be always running but instead has its lifecycle controlled by the Azure platform.

If not IIS Reset, then what?

If you are having trouble with your web application hosted on Windows Azure and think the issue might be related to your IIS host, we recommend the following course of action:

  1. Try to identify the root cause of the failure rather than temporarily relieving the symptom.   https://blogs.msdn.com/b/kwill/archive/2013/09/19/troubleshooting-scenario-5-internal-server-error-500-in-webrole.aspx might be a good place to start, or use Visual Studio to perform remote debugging – .  If you are unable to find the root cause of the problem consider contacting Microsoft Azure Support or posting in the forums where our support team can assist in identifying the problem.
  2. Make sure you have more than 1 role instance so that the Azure load balancer can send incoming traffic to healthy instances.  You may also want to consider implementing a custom Load Balancer Probe so that the load balancer is able to direct traffic correctly when Azure considers the role healthy but IIS is not working correctly.
  3. As a last resort, if you simply need to get your website back online quickly and want to worry about debugging the problem later then perform a restart of the role or a reboot through the Windows Azure Management Portal instead of iisreset.

Follow these steps to bring your website back up:

  1. From inside your Microsoft Azure Web Role or Worker Role, go to Start > services.msc
  2. In the list of Services (Local), scroll down to find “World Wide Web Publishing Service”. Found it?
  3. Now, right-click on “World Wide Web Publishing Service” and click Start. TADA! Your website should be back up.

However, if you website is still unreachable, I recommend going back to the Azure Management Portal and rebooting your VM by going to the INSTANCES tab under your Cloud Service and hitting Reboot on your web role, like this (if you have more than one role instance, you only need to reboot the instance that you ran “iisreset” on):

Hope this helps!

  • Explore

     

    Let us know what you think of Azure and what you would like to see in the future.

     

    Provide feedback

  • Build your cloud computing and Azure skills with free courses by Microsoft Learn.

     

    Explore Azure learning


Join the conversation