Another IIS Blog

A process model is needed to run more than one web-site, web application or web-service securely and reliably on a single machine. In Shared Hosting scenarios hundreds or even thousands of web-sites run on an individual machine. The code running on these web-sites is usually not well tested, if at all. Without a powerful process model the result would be extremely poor reliability. But a process model not only guarantees availability; it also needs to isolate them so that individual web applications don't interfere with each other.

Note: This blog entry used to be on my old blog. I'm about to shut it down so I thought I replicate some of the content here.
Many IIS customers use IISRESET to get IIS back into a vanilla state. IISRESET is a pretty heavy hammer however and not needed most of the time - why would you restart FTP, WAS and W3SVC and all worker processes just because one of your web applications is locking a DLL or some content. Recycling the Application Pool causing the problem is usually enough. If you don't know which Application Pool is making the trouble you can recycle all of them. Here is how you do it with APPCMD:

We were meeting with AdHost today and I gave a quick 30-minute spiel on what we improved in IIS7 when it comes to Shared Hosting. Here is the list (not necessarily complete):

Note: This blog entry used to be on my old blog. I'm about to shut it down so I thought I replicate some of the content here.

Saw a post on forums.iis.net last week about a Podcast on our new IIS7 PowerShell Provider. Being the Program Manager for this thing I thought maybe these guys want me to participate in the Podcast. And sure enough - Jonathan and Hal were interested. And here it is the podcast link and the interview topics:

Instead of writing WCAT scripts I wrote my own little perf test client. The following .PS1 script works pretty well to do some very basic performance testing. Just enter the URL and the duration in seconds, e.g. ".\webperf.ps1 http://localhost/ 15".

Finally, IIS 7.0 has a PowerShell Provider!

There is a 90% chance I have to use the "Failed Request Tracing" feature (FRT) when I'm troubleshooting IIS7 issues. To be honest, I stopped turning it off. Tracing is so useful and fast that I don't see why I should disable it on my development box. I have a rule that catches all requests (status code 200-500) and there is no negative impact.