Are You Ready for IIS 7?

By the time you read this editorial, Microsoft likely has or will very shortly release Windows Vista to manufacturing. If you’re going to develop Web applications with Vista you’ll get Internet Information Server 7 (IIS 7) with it.

If you currently use IIS and you plan to switch to Windows Vista, IIS 7 will be part of the upgrade and with it come a few significant changes in the way the Web server works, installs, and configures. In this article, I’ll point out a few key features and a few things that you need to consider when you start using IIS 7 for Web development on your Vista installation.

IIS 7 is not required for development on Windows Vista any more than IIS 5/6 was required on XP/Windows 2003. If you plan to use the built-in Visual Studio Web Server for all your development, IIS 7 is not required and you don’t even need to install it. However, I personally find that Visual Studio Web Server is annoying to work with, slow, and more importantly, it behaves differently than a real IIS server in many situations-so I tend to use IIS for day-to-day development. I suspect that many of you do the same.

IIS Availability on Windows Vista

Microsoft will make IIS 7 available on all versions of Windows Vista above Windows Vista Home Basic, and IIS will be available on Windows Vista Home Premium. All versions of Windows Vista actually include IIS because it’s required for some of the functionality of the Windows Communication Framework (WCF), but Windows Vista Home and Windows Vista Professional have many common IIS features removed.

Windows Vista Enterprise and Windows Vista Ultimate have full unrestricted versions of IIS running on them, which means that there are no request limits. This is great news for Web developers and one less reason for me to run a server operating system on my main development machine.

Installation

Windows Vista does not install IIS 7 by default. You must install it through Programs and Features | Windows features explicitly. The Web server configuration options are rather extensive. I recommend that you take a little time looking at the various options of modules and features available, and then make sure you install the ones that you actually need. For example, the default settings in IIS are not quite sufficient for a development machine so make sure you enable all ASP.NET-related features.

The default installation options in IIS include the vital IIS 6 metabase compatibility features. Make sure you don’t turn off this option, because most Web development tools, including Visual Studio and just about any Web site installation program, will use this existing functionality rather than the new IIS 7 configuration APIs to set up new Web directories. For example, if you use Web Application Projects, the Create Virtual Directory feature uses the metabase as does Visual Studio 2003 when it creates new Web applications. Any custom Web installation tool built with a Visual Studio Setup Project also uses metabase configuration. I think we’ll use metabase compatibility for some time to come even though IIS 7 provides new configuration APIs that are more powerful and easier to use via Windows Management Instrumentation (WMI).

In the setup options you’ll also want to enable various security features including Windows Authentication, which is required for debugging, in addition to application-level Windows security that your application might use.

Microsoft may change which options are enabled with IIS before final release, so closely review the settings and adjust as needed.

Configuration

IIS 7 stores all configuration settings in XML .config files. Specifically, IIS stores its global configuration settings in an ApplicationHost.config file in the Windows\System32\inetsrv\config directory. ApplicationHost.config is like the machine.config for IIS where many base settings and policies for IIS are stored and the Windows install essentially sets settings in this file.

One very nice feature of IIS 7 is that the configuration XML schema is actually much more logical than previous metabase schemas and especially the horrendous IIS 6 XML schema. In IIS 7, the configuration schema is hierarchical and mirrors behaviors that are similar to the way that ASP.NET web.config files work, using the same scheme of delegation to lower-level directories and web.config files and <location> elements in configuration files to delegate configuration settings to Web sites -> Applications/Virtual Directories.

IIS 7 stores application/virtual level configuration options in local web.config files. If you run with IIS 7 and you change a configuration setting in the new IIS Management Console, the console writes the settings directly into your local web.config file. The changes to the local web.config file get written into a new <system.webserver> section and it may update your existing previously ASP.NET-only web.config file. Don’t freak out when you see the new section in your web.config file. <s>

That’s right! IIS 7 will modify an existing ASP.NET web.config file if you make a change to the local virtual directory settings! You may wonder if that will break your applications with an invalid schema? Nope. Luckily Microsoft built ASP.NET 2.0 with support for the IIS 7 schema so these modifications will not break existing applications even if they are running on versions prior to IIS 7.

Although you might think that these Web server settings are intrusive in your nice and pristine web.config, think of the convenience of being able to store virtual directory configuration options directly inside your web.config. You can, for example, put extension mapping and authentication settings right in this file that you distribute with your application. This feature will make it much easier to do original startup configuration of sites without having to write extensive configuration scripts.

Although you can store many configuration settings in the local web.config files, IIS requires that you set some key settings in ApplicationHost.config globally. So virtual directory assignments and application host mapping and some security settings occur at this higher level. It’s not always easy to know which settings you need to make at which level, but you can use the new Management Console to make the changes for you in your .config files and then examine its changes.

The New Management Console

Probably the biggest outward change for IIS 7 is the new IIS Management Console. The console is very different from the IIS 6 version and it will take a while to get used to the new layout and the many, many options available through this interface. The new console combines IIS and ASP.NET settings in one place, so you can imagine the interface is quite busy with many options available at the virtual directory level. Also, the IIS team changed the terminology on many options so don’t expect that you’ll find specific settings in familiar places.

I think Microsoft made a big improvement by allowing administrators and developers to configure so many ASP.NET options in the new IIS Management Console. For example, you can set AppSettings, ConnectionStrings, and Provider settings right through this interface which makes it easier to enter values quickly, especially for large AppSettings sections. If you’re a little rusty in configuration file syntax, the console is a great way to enter data and get a little interactive help. For example, the IIS Management Console lets you add users and roles, add custom profile settings, configure providers, and so on. In addition, many of the configuration keys also provide basic and advanced options with the advanced options often providing for many IIS settings that you previously could not set through the Management Console interface. The new console is unfamiliar, but I think it’s a big improvement over the old one both in terms of features provided and usability.

Security and IIS Configuration

Security in Windows Vista is locked down pretty tight and the default security will affect many things that you can and can’t do with IIS. Obviously any configuration you need to do with IIS requires administrative privileges. By default, Windows Vista is configured with a pseudo-Administrator account. This is an Admin account, but it doesn’t actually have full Admin privileges. Instead Windows Vista uses User Account Protection (UAP) and a feature called Administrator Approval Mode, which requires entering of an administrative password to explicitly elevate rights to administrator level. The IIS Management Console is one of the applications that has to be elevated.

Another area that’s problematic is debugging applications running under IIS that also require admin privileges. If you want to use IIS for debugging, your only option is to start Visual Studio with an Admin account by using “run as Administrator,” which will force the admin elevation.

Alternately you can decide to disable User Account Control (UAC) and the “pseudo” Admin behavior of the default account by using the Group Policy Editor (gpEdit.msc) and disabling the various UAC settings. Microsoft obviously doesn’t recommend this because this feature is meant as a primary gate against executing any damaging code on a machine even if a hacker has compromised the machine.

However, I’ve found UAC to be such a major annoyance that I’ve turned it off, especially in Web development scenarios. You can do this by using gpEdit.msc and navigating to Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options, and then looking for the User Account Control options on the bottom. The key feature to disable is the “Run Administrators in Admin Approval Mode.” By turning off this option you give an account in the Administrators group true admin rights.

Do this only at your own risk-I suggest you don’t change this setting unless you get to a point where you just can’t make things work the way you need to without going crazy with the UAC prompts <s>.

Integrated Pipeline vs. ISAPI Pipeline

IIS 7 introduces a new Integrated Pipeline, which provides a new Web server request processing API. The new API is defined by a new very ASP.NET-like pipeline that provides many hook points for processing requests. One exciting aspect of the new pipeline is that it integrates .NET directly into the pipeline processing, so request engines like ASP, ASP.NET, PHP, Python, etc., don’t need to use ISAPI any longer for providing application or system-level services if the appropriate handlers are provided.

For ASP.NET the integration is seamless-ASP.NET and the IIS 7 pipeline are basically one and the same in integrated mode so all modules that fire as part of HttpApplication are now firing right out of the IIS engine instead of through the ISAPI interface.

The new pipeline is closely modeled after the ASP.NET Http Pipeline and uses the same concepts of modules and handlers to allow hook points into the pipeline processing. The API provided comes in both native and .NET flavors and the .NET version uses compatible naming conventions as the ASP.NET pipeline. So you will find the same HttpApplication events on the Integrated Pipeline that you have gotten used to with ASP.NET. What this means for you as a developer is that ASP.NET in the Integrated Pipeline can now run without the ASPNET_ISAPI.DLL involved, instead using the IIS 7 pipeline to handle processing of modules and handlers. The new model promises much more control over Web request processing including the ability to hook into core Web server functionality that affects every request fired against the Web server as a whole. You no longer need to write ISAPI handlers or filters to get to this low level; instead, you can use standard ASP.NET-style modules to accomplish most of this functionality.

Beware though that if you run modules and handlers in the Integrated Pipeline mode you have to move the HttpModules and HttpHandlers definitions into the <system.webserver> portion of web.config. IIS 7 will do this automatically for you when you upgrade a Web application/virtual to IIS 7 for the first time, but it will do so only once. For example:

<system.webServer>

<validation validateIntegratedModeConfiguration="false"/>

<modules>

<add name="ContentFilter" preCondition="integratedMode"

type="WebStore.Utility.ContentFilter"/>

</modules>

</system.webServer>

The new Integrated Pipeline mode is the default configuration for an Application Pool. Application Pools originated in IIS 6; like in IIS 6 they provide process-level isolation for applications running in IIS. Each virtual directory must be assigned to an Application Pool and the Application Pool must be configured to run either in Integrated Pipeline mode or use the classic ISAPI mode. Applications/virtuals can run in a single Application Pool.

The good news is that existing ASP.NET applications can run virtually unchanged in an Integrated Pipeline mode Application Pool! According to Microsoft, the compatibility isn’t quite 100%, but in my testing all applications worked without any problems-including those that use fairly sophisticated filtering and UrlRewriting modules. Microsoft points out that any problems are related to modules that access very specific HttpApplication features that are slightly different in IIS 7. I haven’t seen an exact list of which scenarios won’t work, but I also haven’t run into any problems whatsoever while testing existing applications in Integrated Pipeline mode.

So running applications in the Integrated Pipeline is no problem, but if you plan on developing applications with IIS 7 and the Integrated Pipeline using Visual Studio, you currently cannot easily debug. If you run a Web application in Visual Studio under the Debugger against an IIS 7 application in Integrated Pipeline mode application, you will get an error that the debugger was unable to attach to the worker process. Visual Studio 2005 looks for a specific entry point when connecting the debugger and these entry points are not available in Integrated Pipeline mode.

It is possible to debug a Web application in Integrated Pipeline mode, but you’ll need to manually attach the Visual Studio Debugger to make it happen. This gets tedious after a while and there’s no real good way to automate it due to the dynamic nature of the W3WP.exe worker process.

Unless you plan to build specific modules for IIS 7 or for testing IIS 7 behavior, it’s probably best to configure your Application Pools to use classic ISAPI mode so you can debug. For the time being, IIS 7 is not available on the server anyway and Longhorn server is probably still a half year off. For most intents and purposes, ISAPI and Integrated Pipeline mode behavior is interchangeable for typical ASP.NET applications.

Working with IIS 7 Locally and IIS 6 Online: No Problem!

I’ve been running with IIS 7 for development exclusively since early this year and I run Windows 2003 server on my live site. Since then I haven’t run into a single compatibility issue either with old ASP.NET code not running in IIS 7, or with new applications developed with IIS 7 not running on Windows Server 2003. The transition between the two environments has been very smooth.

Fewer Limitations

One thing that drove me nuts with developing Web applications on Windows XP was the fact that IIS 5.1 was limited to ten connections. If you hit more than 10 connections on the local server, IIS would throw a “Server too Busy” error. While for single page testing this is not an issue, this limit made it impossible to do even the simplest amount of stress testing of an application for quick comparisons of pages. It also caused issues when debugging certain types of applications like AJAX pages that create many connections from the client simultaneously and often don’t immediately release the HTTP connection. Locked connections in that scenario often required a Web server restart to clear properly.

The Windows Vista Enterprise and Windows Vista Ultimate versions come with a completely unlimited Web server, so for the first time the client development environment is a full bore Web server you can hammer on. This means there’s no ten-connection limit and you can run full force stress testing on your machine. In fact, recently I was comparing a custom database-driven ASP.NET ResourceProvider against the standard ResX resource provider and wanted to compare the performance difference between the two. Without even thinking about it I installed trusty old WAST (Web Application Stress Test-still the easiest tool to use for quick comparisons) and let it loose on a couple of pages.

The tests against these localized ASP.NET pages managed over 1500 requests a second (for both ResX and database resource providers)! Wow! I didn’t really think about the fact that this is a client installation and only later did I realize that I would have never been able to do this on XP.

Only the high-end versions of Windows Vista provide unlimited local Web server requests. Other versions still have a connection limit of ten simultaneous connections, but rather than erroring out, the requests are queued as to not break applications; however, they might run a little slower in this environment.

Another big improvement in IIS 7 on the client: You can create multiple Web sites. This has been another thorn in my side on XP as you could only have one site configured, which made it difficult to create additional sites for testing or simply for better organization of many virtual directories. You can now create multiple Web sites either with separate IP addresses or host headers.

IIS 7-Good to Go

There’s a lot to like about IIS 7 on Windows Vista and while there are some major changes under the hood, Microsoft has done a great job of keeping the server compatible with existing applications. Kudos on the foresight of building the configuration support for IIS 7 into ASP.NET 2.0 a year before IIS 7 ships! The new features and removal of limitations are a huge bonus for me and I think for the first time I feel confident that I don’t need to install a server operating system on my development machine and still have access to the full Web server functionality.

When the time comes and Longhorn Server ships we’ll be ready for it as it will contain essentially the same IIS 7 although likely in more optimized form. In the meantime we can get used to the new IIS Management Console and get a head start in creating code that is ready for the new server once it releases.