Microsoft’s new Windows .NET Web Server is an IIS-only version of Windows .NET. Like the Standard Server, Enterprise Server, and Data Center Server editions, Windows .NET Web Server uses IIS 6.0, the latest version of IIS. In this Daily Drill Down, I’ll introduce you to Windows .NET Web Server and describe some of the new features and enhancements in IIS 6.0.

Windows .NET Web Server
Like Windows 2000, Windows .NET will be available in several different versions. The various versions of Windows .NET parallel their Windows 2000 predecessors:

  • Windows XP replaces Windows 2000 Professional.
  • Windows .NET Standard Server replaces Windows 2000 Server.
  • Windows .NET Enterprise Server replaces Windows 2000 Advanced Server.
  • Windows .NET Data Center Server replaces Windows 2000 Data Center Server.

Windows .NET Web Server, the new Web Server version of Windows .NET, is essentially a watered-down version of Standard Server. Windows .NET Web Server gives companies a less expensive, more secure environment than Standard Server or other editions of Windows .NET.

You may wonder what makes Web Server more secure than Standard Server if both use IIS version 6.0. Generally speaking, the more features a software product has, the greater the chance that one of those features could be exploited to gain unauthorized access to the system. Because Microsoft specifically geared Web Server toward hosting Web sites, many of the features found in Standard Server, Enterprise Server, and Datacenter were left out.

So what’s left out of Web Server? Below is a list of features found in Standard Server but not in Web Server:

  • Enterprise UDDI Service
  • Internet Authentication Service
  • Network Bridge
  • Internet Connection Sharing
  • Removable and Remote Storage
  • Fax Service
  • Services For Macintosh
  • Remote Installation Service
  • Windows Media Services
  • Terminal Server

Although no specific information is available at this time, according to the Microsoft Web site, Web Server will have limited support for Public Key Infrastructure (PKI) encryption, certificate services, and smart cards. It will also have limited VPN and Active Directory support.

What’s new for IIS 6.0?
Cosmetically, IIS 6.0 looks almost exactly like IIS 5.0, but the entire server architecture has been redesigned. In IIS 5.0, the INETINFO.EXE file was the main Web server process. Rather than relying so heavily on INETINFO.EXE, IIS 6.0 is divided into three main components, each of which uses a new kernel-mode driver. The new components consist of a kernel-mode HTTP listener program called HTTP.SYS, a user-mode process and configuration manager called the Web Administration Service, and an application handler called W3WP.EXE.

W3WP.EXE runs all Web application processes in an isolated worker process, in the name of system stability. Now that you know about the three new components, I’ll discuss each in greater detail below.

The IIS 6.0 kernel-mode driver (HTTP.SYS) is the point of contact for all inbound server requests. HTTP.SYS sits directly on top of the TCP/IP protocol stack so that it can interact directly with the server’s TCP/IP connection. You can configure HTTP.SYS to listen to specific TCP and UDP ports for inbound requests. The HTTP.SYS service manages the client connections, bandwidth throttling, and Web server logging.

The kernel-mode driver links directly to one or more application pools. In IIS 6.0, an application pool is composed of a kernel-mode queue and one or more worker processes. Generally speaking, each application queue manages a separate Web application, and a request is sent to the necessary kernel-mode queue based on its URL.

The cool thing about the HTTP.SYS file is that it’s a system component and doesn’t use any third-party code or share a memory space with any third-party code. To see why this is important, imagine that one of the Web applications you host crashes. In IIS 5.0, a crashed Web application usually means that IIS must be completely restarted, likely disrupting service to other Web sites and applications that the server might be hosting.

In IIS 6, the kernel-mode driver and the associated queues are independent of any Web applications. Therefore, even if a Web application crashes, HTTP.SYS will continue to function, and there’ll be no disruption in service to other Web sites hosted on the server. The server will continue to queue requests for the failed Web application as long as the Web service is still running and the server isn’t out of hard disk space. As soon as IIS notices that a Web application has crashed, IIS will automatically launch a new worker process, with a new instance of the application, and begin routing the queued requests to the new worker process.

Web Administration Service
The Web Administration Service is a core part of the IIS system. Like HTTP.SYS, the Web Administration service is designed to be completely isolated from any Web site code. This isolation ensures that there’s no way for a buggy Web site to crash the Web Administration Service.

The Web Administration Service is responsible for configuration and process management. It’s essentially the bridge between the HTTP.SYS file and the application pools. The Web Administration Service’s configuration responsibilities come into play when IIS is initialized. The Web Administration Service uses metabase information to compile a routing table that maps HTTP requests to the associated application pools. The process management responsibilities include starting, stopping, and restarting worker processes as needed by the system.

The worker process
Worker processes run Web applications and can be automatically restarted if necessary. However, there’s more to the worker process than meets the eye. The main philosophy behind the development of worker processes is that, in order to keep people coming back to your Web site, the site must be dynamic and have ever-changing content. The very nature of a Web site that’s constantly evolving implies that the code behind your Web site will probably never be perfect. This is where the worker process comes in.

The worker process uses something called Worker Process Isolation Mode to run all application code in an isolated environment. In previous versions of IIS, it was possible to run an application in an isolated environment, but doing so hindered the server’s performance. IIS 6.0 is designed to run all applications in separate memory areas with no performance impact.

Each worker process is associated with an individual application pool. No application pool can affect another application pool.

Another unique thing about application pools is that, in IIS 6.0, there’s no longer any existence of in-process applications. All necessary HTTP run-time services, including ISAPI extensions, are available to any application pool. This means that if a Web site were to malfunction, the run-time services that are loaded on the server would be unaffected and would therefore still be available to other Web sites that are hosted by the server.

How can IIS detect a failed process, and, if a process is really malfunctioning, how can IIS be sure that it will be able to shut down the failed process? After all, when a standard application hangs, it’s sometimes impossible to close it.

IIS 6.0 performs something called health monitoring on the worker processes. Health monitoring involves keeping a communications channel open to the worker process. If the communications channel ever drops, IIS assumes that the worker process has failed. IIS then closes the process, if possible, and starts a replacement worker process.

Of course it’s always possible that a worker process could fail but leave the communications channel open. To deal with this possibility, IIS 6.0 relies on a worker process ping. Every so often, IIS pings the individual worker process. If the ping is returned, the process is assumed to be functional. However, if the ping fails, then the process is assumed to be blocked, at which point IIS again terminates the process and starts another one.

So what happens if a worker process is unable to shut down? If IIS is unable to terminate a failed process, it marks the process as being widowed. The process is still open and is still consuming memory, but IIS acknowledges a critical failure with the process and doesn’t try to use it. Instead, IIS opens a new worker process to replace the widowed process.

Another thing I really like about worker processes is that they can be configured to automatically restart every so often. This is because many Web applications have memory leaks and other problems as a result of poor coding. In the past, restarting these Web applications meant disrupting service for the entire Web site. However, IIS 6.0 lets you automatically restart Web applications on a scheduled basis with no noticeable loss of service.

Obviously, the main benefit of worker process is that there’s no way for a malfunctioning Web site to affect other Web sites hosted by the server. However, there’s another benefit to the new design. Because of the way that worker processes function, it’s possible for an individual worker process to utilize specific OS services, such as CPU throttling.

One other feature that demonstrates the dynamic nature of IIS 6.0 is something called rapid fail protection. Imagine for a moment that a worker process fails, is restarted, and fails again. Rather than tying up server resources by constantly restarting an application that obviously isn’t working, an application pool can be automatically disabled after a predetermined number of successive failures. This prevents the multiple failures from slowing down the server’s performance on other applications. When an application pool is disabled, users who try to access the application pool receive a 503 Out Of Service message.

Web gardens
Another cool new feature in IIS 6.0 is a concept known as a Web garden. You’ve probably heard of Web farms, which are large groups of servers that work together to provide load balancing for a Web site. A Web garden is similar to a Web farm, but it works on a smaller scale. Rather than groups of servers working together, a Web garden uses groups of worker processes that work together within a single server to help balance the load.

The idle timeout feature is used in conjunction with Web gardens. Suppose for a moment that, during a heavy period of activity, 10 worker processes are open for a particular application pool. Now imagine that the period of peak activity has ended, and only one of the 10 worker processes is really doing anything. The administrator has the option of configuring the processes so that idle processes shut down after a period of inactivity. Doing so frees up system resources, thus allowing the server to run more efficiently.

Well worth the wait
IIS has been around a long time, and it’s taken a beating. As you can see, Microsoft has made some major changes in IIS 6.0 over previous versions of IIS that make it much more secure and reliable. Best of all, if you’re only interested in IIS and not other Windows .NET features, you can purchase Windows .NET Web Server and save some money.