IISReset is a popular IIS management tool. In earlier IIS versions it was quite often used to restart web servers. Exchange administrators sometimes use this to restart the SMTP service. As a developer I find this handy myself when working on IIS extensions. IISReset with the restart parameter is a quick lazy way to force all services back to a fresh state.
For a quick check of what this tool offers here is what IISReset /? returns. As the parameter options show, the application offers functionality related to stopping and starting the IIS services.
IIS is commonly at the heart of business critical applications where downtime must be minimized. This is one reason why Microsoft does not recommend the use of this tool. A full restart is often not necessary. As the links at the references section explain less drastic alternatives also exist.
Recently I had a chat with an administrator who liked IISReset because of how fast this restarted the services. He was comparing IISReset to the case where he would restart the services through the service control manager.
This is one of the biggest traps of IISReset. This tool doesn't mind using bad manners to do the job. If stopping the IIS services is taking too long IISReset could just terminate the processes. Referring to the TIMEOUT command-line parameter help, the description lists the default length of time IISReset waits for the services to stop. If the time runs out then the process is terminated.
Any software developer like me knows that terminating (aka killing) a process is dangerous. This stops execution without regard to what the process is currently doing. The most immediate risk is that of causing loss of data not yet persisted to storage. This is described by the KB286196 - IISReset May Not Save IIS Configuration Changes.
There is also another less obvious danger. IIS is today at the heart of many other applications. Exchange 200x is one case in point, but there are also many others. If I just focus on my development field, i.e. messaging, you have anti-SPAM, anti-virus, disclaimers and all sort of email integrated applications. So what happens when you run IISReset in this case? Answering this question is quite difficult. The more applications you have tied to IIS, the more this type of process termination becomes dangerous. The effect of IISReset now is dependent on each application integrating with IIS. Of course as a minimum you could be risking to lose information from other applications. More seriously process termination could cause data corruption and at the worst case take down the application completely. I don't want to be too apocalyptic. Fact is that killing a process stops execution at an unpredictable processing stage that could give unpredictable results.
So I think we all agree that terminating a process on a business critical server is best avoided. If you really need to restart IIS use the service control manager, net start/net stop, or IISReset with the NOFORCE parameter. It will take a bit longer, but once the processes are up again you have more peace of mind that the system is back to normal.
References
Restarting IIS (IIS 6.0)
KB286196 - IISReset May Not Save IIS Configuration Changes
KB321674 - HOW TO: Configure IISReset to Wait Longer than the Default Time to Reset Services
Starting and Stopping Services (IIS 6.0)