Caution when stopping and starting an IIS application pool with appcmd

When starting and stopping IIS 7 application pools from command line with appcmd.exe, you should be aware of a behavior that can sometimes lead to unintended circumstances.

To explain it, lets first review what happens when you stop an application pool with the InetMgr.exe tool:

1) Set the autoStart property of the <applicationPool> configuration element to false.  This causes WAS to not start any worker processes when a new request to an application mapped to the application pool arrives.

2) Call IIS RSCA (runtime status and control API) to stop the application pool, which instructs all w3wp.exe processes in that application pool to shut down (gracefully at first, then killed if they exceed the shutdownTimeLimit).  WAS will remember that the apppool is stopped while it is loaded, and any subsequent requests to the apppool will return a 503.

These are two logical actions – #2 being a transient action to terminate the apppool’s current processes, and #1 being a persistent directive not to start the apppool.

Now, lets say you use appcmd in your script to start or stop the application pool, e.g.:

%windir%system32inetsrvappcmd stop apppool “DefaultAppPool”

…

%windir%system32inetsrvappcmd start apppool “DefaultAppPool”

The difference is, AppCmd will only perform #2 – use RSCA to tell the application pool to start or stop.  Because AppCmd does not set the autoStart config property, when you restart WAS (e.g. reboot or do an IISRESET) – the application pool state will be reset and it will be eligible for starting automatically based on the current autoStart setting.

This could mean, that you stopped the application pool, IISRESET, and all of a sudden your application is live again taking load balancer traffic.  If you were debugging/deploying this application in production, this could be bad!

While you may consider this a bug, the argument I had with the software test engineer back in the day was that while InetMgr has to err on the side of convinience and safety, AppCmd should err on the side of flexibility and degree of control, and split these actions. I am not so sure anymore in this case, but at this point it is what it is.

So, if you are using appcmd, be sure to do:

%windir%system32inetsrvappcmd stop apppool “DefaultAppPool”

%windir%system32inetsrvappcmd set apppool “DefaultAppPool” /autoStart:false

OR

%windir%system32inetsrvappcmd start apppool “DefaultAppPool”

%windir%system32inetsrvappcmd set apppool “DefaultAppPool” /autoStart:true

Of course, since these actions are separate, you have flexibility to decide whether you want to perform the start/stop as a persistent action or just temporary until the next WAS reset.

Regards,

Mike