IIS7 - Vista vs. Longhorn Server

I'm often asked the question:  if IIS7 is shipping in Vista, why isn't it also available on a Server OS?  After all, what good is it to have IIS7 only on Vista right now, when I can't actually deploy anything on Vista?

From the looks of Scott's recent blog post on RC1, it looks like quite a few people are asking him the same question. 

IIS Version History

To understand how we think of IIS on a consumer OS like Vista compared to a Server OS, it may help to understand IIS' history.  As far as I know, IIS versions 1, 2 and 3 were only available on Server versions of the operating system.  We released those in 1996 on top of Windows NT 3.5 and 4.0.  IIS 4.0 was released as part of the NT 4 Option Pack in 1997, and was installable on servers as well as Windows 95/98 as "Personal Web Server" or PWS.  I wasn't at Microsoft at the time, but I'm guessing the aim there was to provide IIS as part of the developer platform to encourage ISAPI and ASP development, as well as a basic home web server for the techies.

IIS 5.0 shipped in Windows 2000 - on both the Professional sku (for developing applications) as well as the Server skus (for deploying applications).  At the time, many developers were still on Windows 95/98, for which PWS sufficed.  For those developers moving to Windows 2000, Professional SKU added a built-in option for running IIS in development. 

Windows 2000 started us down the path of only shipping IIS with the operating system, a move which has proven challenging in a number of ways.  Probably most challenging is the fact that in the past six years since Windows 2000 shipped, we've only managed to ship one and a half real releases:  IIS 5.1 on Windows XP in 2001 (which was really just IIS 5.0 with a few small tweaks) and IIS 6.0 in Windows 2003 Server (March 2003).  We're on the cusp of releasing IIS7 as part of Vista, but even 2.5 releases in 6 years is not the kind release cycle I'd prefer for software that plays an important role in an industry that is known rapid innovation and transformation.

IIS 6.0 was a major release for the IIS team, introducing a significant new process model architecture for hosting applications and a HUGE focus on security, in direct response to the Code Red and Nimda exploits for which we had become (negatively) famous.  IIS 6.0 has been a very successful release in a number of ways.  It has enjoyed a rock solid security track record, with only a couple of security bulletins since release more than 3 years ago.  It has also proven to be much more reliable and offer better performance than previous versions of IIS. 

Ever since IIS6 was released on Windows 2003 Server, I've heard developers beg:  can we please get IIS6 on XP?   Since IIS6/Windows 2003 shipped 2 years after XP, it wasn't even close to being ready when XP was originally released, but we did look very seriously at porting it to XP when Windows XP SP2 was in development.  In fact, we filed a request with the XP SP2 planning team to have it included, but the request was unfortunately rejected.  At the time I think people were concerned with the amount of work and risk involved in the project (it would have been a moderately sized project) and to the Windows client team (who was making the decisions) thought that IIS - as an optional component mostly interesting only to developers - wasn't critical to their overall goal of securing the OS for consumers and business.  Given everything the Windows client team had to tackle with XP SP2 I don't blame them for rejecting it, though I would have liked to see it happen. 

Not having IIS 6.0 on XP has been a huge pain for developers, and I still get complaints about this today - 3.5 years later.  It forces developers to choose among several non-optimal options: 

1) Download Visual Web Developer with a built-in web server for development and debugging.  This is probably the best option, though it has only been available since last year.  It offers a compatible, though not feature complete environment for building web applications that will run on IIS.  Though quite good, it mostly provides a simple host to ASP.NET and doesn't enable developers to fully develop and test their applications as they would be able to with IIS proper.  This leads to potential integration issues once the application is moved to testing or deployment.  Security, performance, availability testing, for example, simply can't happen with VWD as things like compression, caching, authentication, among other things, don't work with VS.  With IIS7, the feature differences grows even longer since the built-in Web server can't support features like integrated pipeline and IIS7 support for web.config.  This is something the IIS and VS teams are working on for a future release.

2) Use Windows 2003 / IIS 6.  This is the best option for developers who need to build and test their applications on the same environment as where they will be deployed.  We've heard it isn't a perfect option for a number of reasons.  First, it costs more money, which is never a good thing.  We do have the Web Edition SKU, which is the lowest cost Windows Server sku to help out a bit with the cost of this option, and there are free trial editions available on microsoft.com for anyone wishing to evaluate.  Another reason this doesn't work, however, is that many enterprises don't allow developers to run a Server OS on their desktops by policy.  And last, although Windows 2003 is a great Server OS, it sometimes has limited compatibility for desktop applications and hardware which make it less than ideal for anyone who uses their desktop for more than just web development.

3) Download Apache.  Ugh, I can't believe I listed that as an option.  But for many customers, including those on Windows XP home edition, it is a real option.  

Starting with Vista, we're going to offer much better availability of IIS as part of the client OS.  For the IIS team, Vista is all about enabling Developers to have the latest, greatest version of IIS on which to deploy and test applications.  We're delivering it to developers first, because developers are the ones who make decisions about what platforms they build on, and what technologies they adopt.  To make sure devs have everything they need to be productive with IIS, we've front-loaded all of the new platform APIs and features most applicable to devs early in the cycle and completed them in time for Vista release.  You can basically think of Vista as a feature-complete, developer-ready release of the next major version of IIS.  We hope by shipping it in Vista developers will be able to start evaluation of the new platform early and begin development and prototyping of new applications as soon as possible, while Server development wraps up.

IIS7 on Vista

IIS7 on Vista is for developers to build and test applications, and IIS7 extensions, on our new Web server platform.  For Vista, our goal is to have a feature-complete, developer-ready release that enables developers to:

• build new web applications (including classic ASP, PHP, ColdFusion, CGI, ASP.NET...).  These applications can target IIS6/Windows2003 as a server environment, as well as IIS7/Longhorn Server in beta or release form starting next year.
  
• begin to experiment with and take advantage of new IIS capabilities as part of their applications (things like distributed web.config, asp.net integration, integrated pipeline, caching, authentication, etc.). 
  
• extend IIS using new Web server platform APIs
  

IIS7 on Server

On Server, our goals with IIS7 go well beyond this.  If IIS7 on Vista is all about enabling people to develop applications on IIS, IIS7 on Server is all about enabling people to deploy and operate application in a high performance, high availability way. 

To understand the difference, it may help to think about the ways a Web hosting company uses IIS, for example, and how that differs from the way a typical developers uses IIS on their workstation.  Unlike the typical dev, the Web hoster provisions many hundreds (or even thousands) of customers on the same server.  For each customer they must create at least one IIS site, and often they create a separate ApplicationPool and Windows account to isolate the customer from others on the box.  Sometimes the hoster will then configure the site to take content from a UNC path - from a back-end fileserver or NAS device.  They may also configure a variety of dynamic languages for use on the site, including PHP, ASP.NET, ColdFusion, PERL, and others.  They also may end up configuring the FTP server, to enable publishing to each individual Web site.  Once they've deployed the server, they expect each of the hundreds, or thousands of sites to be able to accept traffic.  They may get hundreds of requests per second, and traffic may come in spikes as one particular sites becomes popular, so they usually end up enforcing bandwidth or filesystem quotas for each customer.  They may provision the server with multiple gigabytes of memory, in order to host that number of sites, and they almost always dedicate the server to pure Web serving.  Most Web devs I know don't have these kinds of requirements on their workstation (or if they do, I wouldn't pay a dime to have my Web site hosted on their desktop!) 

These are the kinds of scenarios that the IIS team is starting to tackle with IIS7 now that our focus is shifting from Vista to Longhorn Server.  Tuning the server for these scenarios takes months and months of testing and bug fixing once we think we've reached feature complete.  We're starting that process now, and plan to have another Beta of IIS7 for Server customer in the coming months.  For the next beta release, we plan to offer broad GoLive availability of IIS7.