IIS Overhauled in Version 6.0

The Microsoft Internet Information Services (IIS) 6.0 story takes a while to tell. It's a good tale and worth reading if you've invested in IIS technologies. I can't tell you everything in one sitting because the differences between IIS 6.0 and earlier versions of IIS are many and significant, so this month, I discuss installation, architecture, and the new server capabilities that the architectural overhaul makes possible. Next time, I'll describe the new features, some of which you probably haven't yet heard about, as well as some important changes in the default settings that might affect your migration.

Installing IIS 6.0
Just to cover the basics, Microsoft included IIS 6.0 with the four Windows Server 2003 servers: Windows 2003, Datacenter Edition; Windows 2003, Enterprise Edition; Windows 2003, Standard Edition; and Windows 2003, Web Edition. Also, to answer the most frequently asked IIS 6.0 question, IIS 6.0 won't be available on Windows XP, Windows 2000, or Windows NT.

You'll see a difference in the Windows 2003/IIS 6.0 experience immediately after Windows 2003 installation. One key change is that Windows 2003, with the exception of Windows 2003 Web Edition, doesn't install IIS by default. This difference is a big break from Microsoft's past philosophy of installing the OS with IIS enabled for many Web applications. You can install IIS in one of three ways: by using the Manage Your Server Wizard, by using the Control Panel Add/Remove Windows Components applet, or by performing an unattended installation.

The Manage Your Server Wizard starts immediately when you first boot your Windows 2003 system. Select Add or remove a role to see several role choices, including Web Application Server (IIS), as Figure 1 shows. Selecting Web Application Server (IIS) and clicking Next lets you optionally install ASP.NET and Microsoft FrontPage Server Extensions. Microsoft's new "Ask before installing anything" IIS policy is a complete about-face for Microsoft and proves the company is taking security seriously.

Using Add/Remove Windows Components proves to be more interesting. When you select Application Server and click Details, Add/Remove Windows Components displays a component list that includes Internet Information Services and some items that previous versions of Add/Remove Windows Components didn't list. Table 1, page 98, shows a comparison of IIS 6.0 and IIS 5.0's Web components. If you install IIS 6.0 from this applet, the result is a Web server that delivers only static content (unless you specify during the installation that you want to enable specific application extensions). If you select IIS and click Details, you see IIS 6.0 subcomponents, which Figure 2, page 98, shows.

You might notice some new options in Table 1, but do you see what isn't there? One significant missing item is Documentation. IIS 6.0 delivers documentation entirely as a Help file—it has no IISHelp virtual directory for you to manage. In IIS 5.0, the Default Web site automatically opened the IIS documentation when you accessed the server locally. In IIS 6.0, you just see an Under Construction screen when you type

http://localhost

Also, IIS 5.0's IISHelp virtual directory contains some error-processing pages implemented in Active Server Pages (ASP). If you use custom or modified Help files and have placed them in IISHelp, you need to create that directory on your IIS 6.0 Web sites.

A closer inspection of IIS 6.0's subcomponents reveals that Internet Services Manager (ISM)—also known as the Administration Web site and installed by default with IIS 5.0 and Internet Information Server (IIS) 4.0—appears to be missing. But if you click World Wide Web Service (one of the IIS 6.0 subcomponents, but not visible in Figure 2), then click Details, you see that IIS 6.0's World Wide Web Service has subcomponents, which Figure 3, page 100, shows. These subcomponents include the Administration Web site, which is now named Remote Administration (HTML), and the Windows 2003 and XP version of Terminal Services Advanced Client (TSAC)—Remote Desktop Web Connection. Notice that you now have the option to add or remove these two subcomponents and World Wide Web Service's other subcomponents: ASP, Internet Data Connector, Server Side Includes, WebDAV Publishing, and World Wide Web Service.

The final way to install IIS 6.0 is to use an unattended installation. This method is still the only one that lets you direct the Administration and Default Web site content to a drive other than the system drive. The Windows 2003 process is identical to Win2K's in that you use Sysocmgr and an answer file to invoke the options you want to install. Of course, new features require new option switches. You can find a list of these switches as of Windows 2003 Release Candidate 2 (RC2) at http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsnetserver/proddocs/datacenter/gs_installingiis.asp.

If you upgrade an IIS 5.0 or IIS 4.0 server to Windows 2003, IIS 6.0 won't be set to start automatically. IIS 6.0 is disabled by default in an upgrade situation except under one of the following circumstances:

Supporting Cast Members
Some IIS features regularly get top billing as the stars of the IIS 6.0 story, but a supporting cast of Internet services that you don't often hear about deserves attention as well. The players include, much to my surprise, POP3 Service and POP3 Service Web Administration. I'm not sure why the POP3 service isn't listed as an Application Server subcomponent or included in the Internet Information Services console, but many administrators have long desired this service as the logical follow-on to the SMTP service (which is installed along with the POP3 service) and as an alternative to the giant Microsoft Exchange Server.

Universal Description, Discovery, and Integration (UDDI) Services is another new Windows 2003 capability and supporting cast member that's related to IIS and not installed by default (note that you can't install UDDI Services on Windows 2003 Web Edition). UDDI is an industry standard (i.e., not a Microsoft invention) that lets you advertise a Web service that's available on your IIS server. I don't mean advertise in the traditional sense—rather, UDDI makes available details that a client (typically a Web browser) needs to know to use a Web service (typically an ASP.NET application). UDDI is still in its infancy, but some companies are using it internally to let developers make code available to other developers. You can learn more about UDDI at http://www.uddi.org and http://www.uddicentral.com.

The final member in the supporting cast is the new Background Intelligent Transfer Service (BITS). This service lets the server dribble out downloads and uploads. Without BITS, if 100 users try to download a 500MB file, your bandwidth takes a big hit, potentially timing out other sessions on the server. With BITS, downloads and uploads use leftover bandwidth rather than consuming all available bandwidth. If this service works as advertised, it could prove very useful—and as a bonus, BITS will be available for Win2K after Microsoft releases Windows 2003. You can read about BITS at http://www.microsoft.com/windows.netserver/techinfo/overview/bits.mspx.

Building the Foundation
IIS 5.0 and IIS 4.0 are built on the same software architecture: They're user-mode applications that deliver Web applications either under the System account in the Inetinfo process or as the IWAM user outside the Inetinfo process. IIS 5.0 performs quite well under load, but our expectations for Web servers have changed. To move IIS from hosting 1000 Web sites to 10,000 Web sites or more, while at the same time improving security and reliability, Microsoft had to eject the core and build a new one.

Another reason for laying a new foundation for IIS is that Microsoft (and other vendors) have learned that poorly built applications are by far the most frequent cause of Web server performance and reliability problems. IIS 5.0 mitigates these problems with the Pooled ­ Out of Process container for Web applications. In IIS 5.0, a failed application running in the Out of Process pool might not crash IIS because the application is running in a process other than Inetinfo, but all Web applications running in the Out of Process pool will halt, and all applications run in the pool by default. Troubleshooting is difficult in this situation because determining which application caused the problem is difficult. IIS 6.0's new architecture solves these problems by isolating the tasks of listening for requests, creating and monitoring Web sites, and running Web applications. In theory, the new architecture results in big improvements in availability, security, and performance. In practice, Microsoft and beta testers report that they're seeing dramatic improvements in stability and performance. The IIS 6.0 architecture relies on three major components: W3SVC, http.sys, and the W3Core.

W3SVC. W3SVC is perhaps the least heralded component of the IIS 6.0 architecture but is nonetheless significant. W3SVC creates and monitors worker processes (which run Web site applications) according to the metabase settings. In IIS 5.0, the closest relative of the IIS 6.0 W3SVC component is the IIS Administration Service, which is part of Inetinfo; consequently, if Inetinfo fails, the IIS Administration Service also fails and can't restart Inetinfo or other failed applications. In IIS 6.0, W3SVC operates as an independent process that a Web application failure can't crash because no third-party code runs in W3SVC. W3SVC is always running, so it can monitor the availability of Web applications and take action if required. This approach lets the server monitor and restart applications based on parameters you provide.

Http.sys. The most radical new aspect of the IIS 6.0 design is the addition of the http.sys driver, which processes HTTP requests and operates in kernel mode. Moving the task of processing HTTP requests from user mode in IIS 5.0 and IIS 4.0 into the kernel in IIS 6.0 marks the beginning of a new generation of IIS servers.

In Win2K and NT 4.0, IIS runs in user mode, which is the OS mode in which applications run. Applications running in user mode don't directly communicate with the hardware. Instead, they invoke standard procedures that transfer data to or invoke functions of kernel-mode components (e.g., NIC drivers, graphics subsystems) to complete a task such as saving a file, setting an IP address, or sending an HTML file to the network.

Transitions between user mode and kernel mode are expensive. Microsoft servers transfer the incoming HTTP request from the TCP/IP stack in the kernel to Winsock running in user mode, which then transfers the request to IIS. The shift from kernel mode to user mode occurs quickly but does introduce a momentary pause into the process. Under load, such momentary pauses can add up, and since these transitions are required, you can't optimize the process.

The IIS 6.0 http.sys kernel-mode driver significantly reduces the number of transitions between user mode and kernel mode. Http.sys listens for HTTP requests and determines which user-mode process should handle the request or whether the driver can deliver the requested content.

IIS 6.0 running in user mode completely depends on the kernel-mode http.sys as the server's engine for receiving user requests. Consequently, the driver must be responsive and reliable. Thus, Microsoft designed the driver so that it doesn't execute any user code that might crash it. As a result, a failed application can't cause IIS 6.0 to stop listening for HTTP requests.

A high-speed kernel-mode HTTP processor that can't run applications is perfect for returning requests for static or unchanged content directly from a kernel-mode cache. This setup reduces expensive transitions to user mode, and a response returned from a kernel-mode cache is fast. IIS 6.0's http.sys manages such a cache and uses much improved caching heuristics to determine what information should be cached. For example, http.sys might require more than one request for content before caching it.

Because http.sys delivers static content from the response cache without shifting to user mode, overall IIS 6.0 performance improves significantly over IIS 5.0 performance. Microsoft presentations have shown WebBench benchmarks in which IIS 6.0 delivers static content about 150 percent faster than IIS 5.0. Even if you run the IIS 6.0 server in IIS 5.0 isolation mode (which causes IIS 6.0's architecture to mimic IIS 5.0's), you benefit from the response cache and other improvements in the http.sys driver.

Additionally, Microsoft optimized the http.sys driver to route requests directly to the correct worker process. IIS 5.0 and IIS 4.0 rely on several steps to determine which instance of a process contains the Web application that should receive a request. Http.sys registers all IIS 6.0 applications and assigns them each a handle that IIS uses internally to identify one or more namespaces that the registered application uses. Thus, when http.sys receives an HTTP request, it can quickly route the request from http.sys's kernel mode to the correct Web application in user mode.

The http.sys listener performs some other tasks as well, such as

Because http.sys is an OS driver rather than an IIS component, you use registry settings instead of the IIS metabase to configure the driver. Currently, many of http.sys's registry settings are undocumented. This lack of documentation suggests that Microsoft might be discouraging user modification of these settings because it's planning changes to them. The http.sys driver registry settings are at HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesHTTP, at which you can add registry subkeys (that aren't present by default) such as

The %uNNNN form of Unicode notation isn't frequently used. Don't confuse it with the more common UTF-8 form in which %20 represents a space, such that http://www.iisanswers.com/new article.htm is equal to http://www.iisanswers.com/new%20article.htm. Microsoft Internet Explorer (IE) automatically manages UTF-8 transformations, and IIS 6.0 accepts them regardless of the EnableNonUTF8 and PercentUAllowed settings.

These two settings for http.sys, plus others you can find in the IIS 6.0 documentation, represent improvements in the way IIS 6.0 interprets URLs. Some of the most serious problems with IIS 5.0 security relate to the way IIS 5.0 parses URLs. Microsoft has eliminated those vulnerabilities and made other improvements to let you more clearly specify what rules IIS 6.0 should use to decode a URL. These improvements are particularly important for an international Internet in which various languages are represented.

For more information about Unicode, see http://www.unicode.org. For more information about the IIS 5.0 vulnerabilities, see http://www.wiretrip.net/rfp/p/doc.asp/i5/d57.htm. Look for a utility in the Microsoft Windows Server 2003 Resource Kit to assist with configuring http.sys.

W3Core (application pool). By default, IIS 6.0 runs in worker process isolation mode, which Figure 4, page 102, shows. In this mode, IIS 6.0 uses a separate instance of w3wp.exe, also called a worker process or a W3Core, to run each Web application. Consequently, worker process isolation mode has no such thing as an in-process application. The result is improved reliability and security. Reliability improves because Web applications don't interfere with one another, can't crash http.sys, and are independently monitored by W3SVC for availability. Security improves because applications don't run under the System account as do in-process applications in IIS 5.0 and IIS 4.0. By default, all instances of w3wp.exe run under a limited-privilege Network Service account, which Figure 5 shows. Alternatively, you can configure the worker process to run under another user account.

In the event of a successful buffer-overflow attack on a Web application, the intruder can access only resources available to the user account running the worker process under attack—by default, the Network Service account. The Network Service account doesn't have Write access to the Inetpub folder or Execute access to most of System32, so a CodeRed worm attack (for example) has no place to go.

Some Web applications, particularly Internet Server API (ISAPI) filters, might cause problems when they run out-of-process. In IIS 5.0 and IIS 4.0, ISAPI filters always run inside Inetinfo, so they didn't need to be designed to run out-of-process. Consequently, some filters will fail when run in IIS 6.0's worker process isolation mode—specifically, filters that call SF_READ_RAW_DATA or SF_SEND_RAW_DATA. IIS 6.0 has a second mode of operation called IIS 5.0 isolation mode. ISAPI filters that don't run well in worker process isolation mode should run correctly in IIS 5.0 isolation mode, and your applications will still benefit from many of the IIS 6.0 improvements, including the speed and availability that the http.sys driver provides.

You'll see references to an IIS 6.0 feature called application pools. An application pool is a worker process (or set of processes) with a name. Think of it this way—in IIS 5.0, you can set Application Protection to Low (IIS Process), Medium (Pooled), or High (Isolated). This capability is useful, but what if you want to run two applications in one pool (an instance of dllhost.exe) and two different applications in another pool (a different instance of dllhost.exe)? IIS 5.0 offers no way to name instances of dllhost.exe and assign applications to those names. IIS 6.0's application pools let you assign a name to a worker process, as Figure 6 shows, so that you can assign Web sites or directories to that pool, as Figure 7 shows.

Pool Party
Now that we've looked at IIS 6.0's key architectural components, let's see what we can do with an application pool. An application pools Properties dialog box has four tabs—Recycling, Performance, Health, and Identity—which Figure 5 shows. Of these, perhaps the most significant is the Recycling tab. This tab's option tells W3SVC to recycle (i.e., stop and start) the application pool running your Web applications based on the number of minutes since the process started, the number of get requests, the time of day, or the amount of memory consumed. By default, application pools are recycled every 1740 minutes (29 hours).

W3SVC determines whether a pool is healthy based in part on the Health tab options, which include Ping worker process every (frequency in seconds), Worker process must startup within (time in seconds), and Worker process must shutdown within (time in seconds). Furthermore, ISAPI applications (including ASP.NET and asp.dll) can declare themselves unfit for service and request to be recycled.

By default, when IIS 6.0 recycles a pool, it uses a technique called overlapped recycle. In this mode, the failing worker process keeps running while a new worker process starts up. IIS 6.0 delivers new requests to the new worker process but doesn't destroy the old worker process until the old worker process serves the requests in its request queue or timeouts kick in. TCP/IP connections aren't lost because http.sys maintains them. When the failed worker process times out, the next request to the new worker process is new, so session information stored in the process is lost. All this recycling occurs without administrative intervention and in many cases, without noticeable interruption of service. You'll probably want to set the metabase property LogEventOnRecycle to True (1) to instruct W3SVC to make an entry in the event log when a recycle occurs.

Overlapping recycling might pose problems for applications that can't be multi-instanced. If so, you can set the metabase entry DissallowOverlappingRotation to True (1) to turn off overlapping for an application pool. Instead of destroying a failed worker process, you might want to keep it around for advanced troubleshooting purposes. To do so, set the worker process's metabase property OrphanWorkerProcess to True (1). You can also set the metabase property OrphanActionExe to the name of an executable to let that executable keep running when a worker process is orphaned.

Another feature related to application pools is the ability to configure an application pool to become a Web garden. One way to conceptualize a Web garden is to think of an IIS 5.0 server with three Web sites, each hosting the same application. If IIS 5.0 could automatically send traffic to each of these identical, yet distinct Web sites in a round-robin pattern, distributing the load to three different processes, you'd have a small version of a Web farm—thus, the term Web garden.

In an IIS 6.0 Web garden, you don't need to create the additional Web sites, you just specify the number of worker processes you want to use for an application pool. To do so, open the application pool's Properties dialog box, go to the Performance tab, click Web Garden, and enter a number in the Maximum number of worker processes option. When the load on the server is such that additional worker processes aren't being used, IIS 6.0 will tear them down after a configurable timeout (20 minutes by default). When needed again, IIS 6.0 will spin up a worker process. All of this occurs without administrative intervention.

Application pools (including Web gardens) give you another new capability. Two new metabase properties—SMPAffinitze and SMPAffinitzeCPUMask—let you assign an application pool to a CPU so that you can optimize CPU use for your Web applications.

Just when we're starting to have fun, I'm out of space. I've tried to provide a more complete explanation of the new IIS 6.0 architecture than you typically see. In Part 2, I'll cover more new features. You'll find that many have been on the wish list for a long time, but some are significant surprises.