DON’T Use IISRESET to Restart Your Website

One popular tool for restarting your IIS services is IISRESET.

Regretfully, that is also its main issue:

1. It is frequently used to detect configuration changes and reset IIS websites that aren’t functioning properly.
2. It actively compromises both the general stability of your server and the accessibility of your webpages.

We’ll go into great detail on this reason and how IISRESET affects your IIS services in this post.

See our Reset, restart, and recycle IIS guide for more information on how to properly reset IIS, restart your apps, and recycle your application pools.

Prior to delving into every aspect of how using IISRESET to restart IIS can impact your web server, let’s recap the purpose of IISRESET.

Why is the command IIS RESET used?

Typically, for one of two reasons:

To detect configuration modifications

This brings back memories of the past, when it might have been required to reset IIS in order to detect modifications to registry keys and certain IIS configurations.

All IIS services in versions 7.0 and higher normally detect and apply any changes to the configuration and content of the applications. These modifications are either automatically handled or cause the relevant system components—such as the application or application pool—to restart.

In summary, IISRESET is never required in order to detect configuration changes. See the Reset, restart, and recycle IIS guide’s section on ensuring that IIS has picked up the website, application pool, or configuration changes for full details on this.

To overcome problems with stability or performance

This includes memory leaks, high CPU usage in your IIS worker process, hangs, and slow website performance, among other issues.

Restarting the application is not the best solution for any of these problems.

Resetting IIS is never the right course of action, even in situations where it makes tactical sense. As an alternative, choose the appropriate application pool and recycle it (or, in some circumstances, end the IIS worker process). There are numerous advantages to recycling, such as:

• Impacting just the relevant application pool.
• Overlapping IIS recycle results in a zero-downtime restart.
• Restarting with no startup delay and complete warmup
• No impact to other websites.
• No possible repercussions for the web server as a whole.

Please refer to the reset, restart, and recycle IIS guide for all the information on how to accomplish this.

You might not care that IISRESET is actively harmful now that you are aware of its needlessness. If you do, though, let’s continue with that.

How IISRESET works

Pulling the power cord out of your server to end a particular application is the most realistic analogy. Yes, it will work; the application will close; however, in the process, you may corrupt some data and possibly drop your server to the ground. You will need to wait for the server to restart its boot process in order to use it once more.

I find that using a rusty hammer to do pretty much anything is a more entertaining analogy. IISRESET is an antiquated, rusty hammer that is unquestionably the incorrect instrument for any task.

Basically, this is what occurs when you use IISRESET:

1. It aims to terminate WPAS/Windows Process Activation Service, also known as WAS, the Windows Activation Service.
2. This terminates all WAS-dependent services, such as W3SVC.
3. WAS makes an effort to close ALL open application pools.
4. This implies that while WAS is stopping, all incoming requests to each website hosted on your server will start receiving the 503 Service Unavailable response.
5. At this point, we’re waiting for the completion of any open requests in order for all IIS worker processes to cease. up to the default shutdownTimeLimit of ninety seconds.
6. A worker process will be terminated if it does not stop within this time frame.
7. After about 90 seconds, WAS finally stops.
8. After that, IISRESET tries to restart W3SVC and WAS.

That is, unless WAS are forcibly stopped by IISRESET, which times out while waiting for them to stop.

In that scenario, there’s a good chance that the command will not work and won’t restart the IIS services that were stopped, rendering your web server inoperable forever.

You should be able to see why this is a very, very bad idea by now.

How the availability of your web server is harmed by IISRESET

Next, let’s examine the very real repercussions.

IISRESET causes downtime for your website(s)

Remember that the W3SVC service terminates as soon as possible. This indicates that connections are being rejected and no one is listening on the website bindings. This takes effect right away for EVERY website hosted on your server.

We aren’t even discussing errors in the IIS logs or a 503 Service Unavailable error message. We are discussing the “this website does not exist” situation and the lack of a record of any unsuccessful requests.

Compared to other methods of restarting your applications on the server—namely, the IIS application pool recycle—this is a fundamentally worse experience. In contrast, the overlapped recycle provides a restart experience with no downtime. The option to reset your applications with full warmup is not even included in this.

The entire server experiences LONG downtime due to IISRESET.

Another important thing to know is that IISRESET stops ALL application pools on the system because it isn’t directed at any particular website or application pool.

This means that the longest time any worker process in an application pool takes to complete a request that it is currently executing (up to their shutdown time limit) is the downtime for ALL websites.

Because IIS is typically reset in response to a performance issue (such as a hang or CPU overload), there is a high likelihood that some of those requests will take an extremely long time to complete. Therefore, each time you call iisreset, be prepared for the entire 90-second delay.

During this period, EVERY website is unavailable.

It might cause your server to become inoperative.

Returning to that shutdown timeout, let’s.

The default timeout for IISRESET is 20 seconds. not the standard application pool shutdown time limit of ninety seconds.

Accordingly, on an active system, IISRESET will always time out before WAS can come to an end. resulting in an attempt to forcibly end WAS.

The best part is yet to come.

Even when you are running IISRESET as Administrator, this frequently results in a permission error. This is where the mistake is:

Your server is now permanently down and your WAS and W3SVC services have been terminated as a result:

Let us assume that you were utilizing the IISRESET NOFORCE command as recommended by Microsoft support. The /NOFORCE command will probably cause the stopped state to persist until the timeout is exhausted (without terminating the services).

The improved IISRESET command line to use

If you must use IISRESET, you can use the enhanced restart IIS cmd, which has a lower failure rate, on IIS 7.0 and higher:

iisreset /stop /timeout:60
taskkill /F /FI "SERVICES eq was"
iisreset /start

This is more effective because it does not generate the “Access denied” error that occurs when using the default IIS restart command. It functions by utilizing an extended timeout, and in the event that IISRESET stop does time out, it ensures that WAS is completely terminated and then restarted. By doing this, you can avoid taking down your web server permanently.

You are not able to resolve your performance problems by using IISRESET.

Is IISRESET being used as a temporary fix for issues such as memory leaks, hangs, excessive CPU usage in your IIS worker process, or just generally subpar website performance?

In that case, all you’re doing is aggravating the issue. You’ll always be caught in a cycle of “cause downtime to solve downtime,” and these issues will inevitably resurface.

Alternatively, you can utilize these times as highly valuable chances to identify and fix your performance problems. and when you’re ready, use high precision recycling sparingly to clear them.

You are deprived of the advantages of overlapped recycling and full warmup.

Really? Instead, the recycle method allows you to restart an application pool with zero downtime, full warmup, and no startup delay if you are attempting to restart a malfunctioning or unresponsive application pool.

As opposed to IISRESET’s downtime, warmup-free, full startup delay option.

Conclusion

Use of IISRESET is not advised. It’s never necessary to reset your server’s IIS.

It can render your web server inoperable and cause prolonged downtime for your websites.

Instead, read our guide on how to properly restart your IIS services and WHEN to do so by visiting our Reset, restart, and recycle IIS page. While you’re there, take a look at our instructions on configuring your website for 100% warm, startup delay-free operation.

You’ll be happy that you did.

IISRESET FAQ

These are the responses to some of the most common queries regarding IISRESET.

Why is iisreset required?

IISRESET was only included for backward compatibility and is deprecated in any version of IIS after 7.0. In all cases, you should always try to perform an app pool recycle instead.

What does IISRESET do?

All IIS services are restarted by IISRESET, which also ends any running IIS worker processes and terminates them if they don’t terminate quickly. All of the server’s websites experience downtime while the web server is restarting and stops accepting new requests. The World Wide Web Publishing Service (W3SVC), IISADMIN, WPAS, and any other services that depend on them are among the services that have been stopped.

On IIS versions 7.0 and higher, the IISRESET command is deprecated and should not be used. Rather, you should restart the particular application pool that is having issues by using application pool recycling.

How do I use IISRESET?

After IIS 7.0, you should not use IISRESET on any version of IIS. This is due to the fact that IISRESET is superfluous and prolongs the downtime of websites. Furthermore, if the command is unable to restart the IIS services, there is a significant chance that the web server will go offline permanently.

When should I run IISRESET?

The right response is never. For IIS 7.0 and later versions, an IISRESET is no longer required.

IISRESET also has a number of negative consequences on your web server, such as extended downtime and the possibility that IIS will shut down permanently if the command is unable to restart the IIS services. Attempting to recycle the target application pool is always a better option.

Does IISRESET recycle the application pools?

No is the appropriate response. Rather, IISRESET shuts down all running IIS worker processes and terminates them if they don’t terminate quickly enough. The overlapped application pool recycle, which initiates a new worker process instantly to handle any new requests so that no requests are lost, is significantly different from this.

Instead, IISRESET stops the application pools, resulting in both short-term and long-term downtime. Because EVERY application pool, not just the one that is being recycled, needs to stop in order to finish the IISRESET process, the downtime is prolonged.

What is IISRESET stop?

All IIS services are terminated by the IISRESET STOP command. This entails terminating any running IIS worker processes and killing them if the worker processes don’t stop in time. The web server stops listening for any incoming requests during the stop. The World Wide Web Publishing Service (W3SVC) cannot be started manually or until the server restarts after the stop is finished.

Versions of IIS 7.0 and higher should not use the IISRESET command. Instead, use the following command to stop and disable the WAS service in order to stop IIS: net stop WAS /yes && sc config WAS start= disabled.

Which IIS services does IISRESET restart?

WPAS/WAS, the Windows Process Activation Service, is essentially restarted by IISRESET. The additional IIS service names for the impacted services are as follows: Web Management Service (WMSVC), FTP Publishing Service (FTPSVC), IIS Admin Service (IISAdmin), and World Wide Web Publishing Service (W3SVC).

Yury Sobolev

Yury Sobolev is Full Stack Software Developer by passion and profession working on Microsoft ASP.NET Core. Also he has hands-on experience on working with Angular, Backbone, React, ASP.NET Core Web API, Restful Web Services, WCF, SQL Server.