IISRESET: the (almost never) good, the bad and the ugly

Adam Rash http://iotacons.blogspot.com/

Now that Epicor ERP is using a pure Microsoft stack there are some habits that are in heavy use that once were considered OK but now are no longer considered best practices. As with any new technology, those of us learning it as we go along are beholden to the experts to help us avoid pitfalls. This post is to discuss one of those behaviors with IIS that is so ingrained into our collective IIS admin psyche that even those that know about it fall into the trap of using it from time to time; this is of course regarding the (over)use of IISRESET.


Let’s take a trip in the way back machine to help us determine the good, the bad and the ugly of IISRESET.

In the early versions of IIS (1.x - 4) the most common course of action to recover from an unresponsive application was to restart the entire server. Microsoft realizing that restarting the entire server for those conditions was overly aggressive created a command that would allow for restarting the IIS services when an application became unresponsive instead of needing to resort to a server restart - that command was of course the (in)famous IISRESET. (the good, at the time) IISRESET was a new feature in IIS 5 (which shipped with Windows Server 2000) and it was the first time there was an explicit command to restart all of the IIS services but beginning with IIS 6 MS stopped recommending IISRESET and, per MS isn’t actually supported in IIS 7+ (Windows 2008+) (the bad - no support and MS isn’t recommending it). Why did they stop recommending it? An excerpt from MS via technet article(here comes the ugly): (emphasis below is mine)

“Restarting or stopping IIS, or rebooting your Web server, is a severe action. When you restart the Internet service, all sessions connected to your Web server (including Internet, FTP, SMTP, and NNTP) are dropped. Any data held in Web applications is lost. All Internet sites are unavailable until Internet services are restarted. For this reason, you should avoid restarting, stopping, or rebooting your server if at all possible.


QUESTION 1: I’ve used IISRESET 100’s of times with no (obvious) ill effect. Why shouldn’t I continue to use it?
RESPONSE 1: IISRESET is like pulling the power cable directly out from my server’s power supply when all you want to restart the machine. Most of the time there isn’t any visible difference in the outcome between the two methods, but, we can all agree that using the restart option in Windows is better than a severing of all power to the server.

QUESTION 2: That was a silly simile and has no comparison to what IISRESET really does. What do you think about that?
RESPONSE 2: Well, similes are as hard as…peach pits? herding voles? frozen lime gelatin with carrot shavings?

QUESTION 3: I know I’ve seen Epicor documentation that tells me to use an IISRESET, right? Let me dig up those emails that included a hot-fix and check…
RESPONSE 3: You’re absolutely right. Some of our documentation, like what may accompany a hot-fix, tends to use IISRESET when the goal is to simply “restart” the appserver processes for some new server-side assemblies to take effect. We’re working on addressing that. In the meantime, let’s talk more about alternative methods to accomplish the same goal as an IISRESET when we apply a hot-fix in a bit. I assure you there is a one line replacement to IISRESET that will recycle all started application pools from a command line*.

QUESTION 4: When is an IISRESET ever an appropriate course of action?
RESPONSE 4: One could argue that it would be appropriate when installing ISAPI filters or some other System level changes. That said, in those circumstances it would be recommended to simply restart the entire server in those few edge cases where you need something more aggressive than a simple application pool recycle. Basically, in a production Epicor IIS environment that was working, an IISRESET shouldn’t be necessary as a normal maintenance process.What we are left with in regards to IISRESET is that at best it isn’t supported by MS and at worst it just shouldn’t be used because it is “a severe action”. Well, now we know and knowing is half the battle.


What do we do if IISRESET shouldn’t be used? It depends on the objective. If the goal is to restart an appserver process after applying a hot-fix, or regenerating a data model, or some other activity that only affects a subset of all appservers on the server, then look at option 1, 2, and maybe 3. If the goal is to quickly recycle all appservers on the server without an IISRESET (e.g. you just regenerated the data model against all databases because extended UD fields were added to all of your databases) then consider option 4.

I believe that everyone should have a script like option 4 on their Epicor server to restart all appserver processes just in case. It is better to have it and not need it, then to need it and use IISRESET instead.

I’ll be assuming the appserver name that we will be recycling in Options 1-3 is EpicorERP10. Adjust the steps accordingly if your appserver name is different.

OPTION 1 - Epicor Administration Console GUI:

  1. Launch the Epicor Administration Console on your Epicor IIS server.
  2. Expand Server Management > Name of your Server.
  3. Right-click on EpicorERP10 and select Recycle IIS Application Pool. When prompted “…Are you sure?” click Yes.

OPTION 2 - IIS Manager GUI:

  1. On your Epicor IIS server, click the Start button(or open a Run line) then type ‘inetmgr’ without quotes and press Enter.
  2. Expand the name of your server, and click on Application Pools.
  3. Right-click on EpicorERP10 and select Recycle…


  1. On your Epicor IIS server, launch an elevated command prompt.
  2. Type (or better yet, copy and then paste into the command window) the following and press Enter:

%systemroot%\system32\inetsrv\appcmd recycle apppool /apppool.name:EpicorERP10

OPTION 4 - RECYCLE ALL STARTED APPLICATION POOLS (aka: Appservers) FROM A COMMAND LINE - 1 line exactly 100% like IISRESET as I promised:
(*I have taken some liberties to make it one line - as you’ll see in the screenshot, it is technically one line if your screen can display at least 189 characters + the folder path, if not, it rolls into additional lines like my screenshoot actually shows):

  1. On your Epicor IIS server, launch an elevated command prompt.
  2. Type (or better yet, copy and then paste into the command window) the following and press Enter:

%systemroot%\system32\inetsrv\appcmd list apppool /state:Started /xml | %systemroot%\system32\inetsrv\appcmd list apppool /in /xml | %systemroot%\system32\inetsrv\appcmd recycle apppool /in


  • IISRESET should really be avoided. It is rarely (if ever) a good course of action in modern versions of IIS on a production server, and 99.9999…% of the time it is either a bad or just plain ugly option. The more granular the action, the better - especially in a production environment and IISRESET is a kick to the head when all you are actually trying to do is take off your hat. Yes, a kick to the head may in fact take off your hat, but, there are simpler and generally far less painful ways to accomplish the goal.

  • There are many alternatives to IISRESET when the goal is to restart application pools/appserver processes; both GUI driven and scripted options possible.

Go forth and spread the word about IISRESET.

P.S. Powershell’s IIS administration snap-in and custom cmdlets are much more powerful than what appcmd can provide but it was more involved than the scope of this post. To read more about this, click here for a technet article.

Opinions expressed are solely my own and do not express the views or opinions of my employer.


If anyone does get a set of one-off / hot-fix instructions from Support as of January 19th, 2017 where you are directed to complete an IISRESET after applying the updated assemblies, please kindly complete an application pool recycle instead. Additionally, if this happens, if you could let me (naanderson AT epicor DOT com) know the case number that you received the one-off / hot-fix instructions for I’ll get to the bottom of how that happened. As of today, no instructions from Support should include an IISRESET.

Many thanks.