What's New in IIS 6.0 in Windows .NET Server
- New Architecture and Processing Model
- WMI Provider
- Command Line Administration
- Passport Integration
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Now that Windows XP Professional and Home editions have been released, Microsoft has realized its 10-year vision of evolving its Windows code bases into a single operating system going forward. This convergence of business and consumer operating systems will not be complete, however, until Windows .NET Server (formerly known as Windows 2002 Server, Windows XP Server, and Whistler) ships in mid-2002.
As mentioned in my previous article on Component Services, although Windows .NET Server is currently in the beta cycle (beta 3, the last beta was scheduled to be released in November), it is already evident that there will be plenty of new features for IT folks to chew on. In addition to the user-oriented changes inherited from the Professional and Home editions (such as Internet Explorer 6.0's new UI, Dynamic Update, System Restore, and Windows Media Player 8), the server edition will include new administrative and development features. Among these are Component Services 1.5 (discussed in the previous article), Active Directory administration and management improvements, MSMQ triggers and Internet messaging, and snapshots.
In this article, however, I want to limit the discussion to four of the new features of Internet Information Server 6.0 that Web developers and administrators can take advantage of when designing and deploying Web applications for use on Windows .NET Server.
New Architecture and Processing Model
Perhaps the most significant set of changes in IIS 6.0 from previous versions are the result of the new architecture and processing model it incorporates as depicted in Figure 1. At the most basic level IIS 6.0 introduces a new kernel mode driver, HTTP.SYS. This listener resides in the kernel and sits directly atop TCP/IP, acting as the single point of contact for all HTTP requests. In addition to being responsible for connection management, request queuing, bandwidth throttling, and logging, HTTP.SYS implements static and dynamic caching which allows an application to set its caching policy and increases performance by ensuring that a cache hit is serviced completely in kernel mode without a transition to user mode.
){kind=link}
Figure 1 The IIS 6.0 architecture, adapted from a PDC 2001 presentation.
By abstracting these core IIS services, as depicted in Figure 1, HTTP.SYS allows applications to be segregated into pools by configuring them to run in dedicated application mode. Basically, dedicated application mode allows an administrator to configure one or more applications to run in separate and isolated Web service processes referred to as worker processes. Previous versions of IIS allow you to configure applications either to run separately in their own dedicated process or in one shared separate process, but do not allow applications to be pooled. By using dedicated application mode, each application or group of applications can be isolated and configured more flexibly so that if one application experiences problems, it will not take down the others. This is not the case in previous versions of IIS because by default, user code and ISAPI are loaded into the core Web server process INETINFO. So if the user code or ISAPI experiences an access violation, the entire Web server is affected. With dedicated application mode, only the worker process that experienced the violation is terminated. In the event of an error, the Web service (W3SVC) even starts up a new worker process to replace it. Although applications can and should be configured to run in dedicated application mode, a standard application mode is still available to ensure backward-compatibility for applications that take advantage of advanced ISAPI features such as read-raw data filters.
To configure an application pool, you can simply use the Internet Services Manager, as shown in Figure 2. By default, a Default Application Pool is created into which all applications are placed. In this example, in addition to the IIS applications that are automatically installed, a custom application called ACME has been created. The custom application can then be manipulated through the UI and placed into a separate pool.
){kind=link}
Figure 2 Configuring an application pool.
By right-clicking and selecting Properties from within the Internet Services Manager, an application pool can be configured with its own processing characteristics. For example, you can specify the process recycling, performance, and health-detection features on each individual pool. The resulting Pool Properties dialog box, as shown in Figure 3, can be used to recycle worker processes based on uptime, a schedule, number of hits, and memory consumption. In this way, administrators can be proactive by making sure an application does not leak resources over time and affect the health of the server. If a worker process will be recycled, it is given a configurable amount of time to finish all the requests it is currently processing while new requests are routed to a new worker process by HTTP.SYS.
){kind=link}
Figure 3 Recycling worker processes.
In addition, an administrator can use the Performance tab to configure the application pool to terminate or orphan a worker process after a certain amount of idle time in order to save resources, limit the number of requests that can be queued to a pool, and even configure how many worker processes are spawned for each pool (referred to as a Web Garden). The Debugging tab can be used to attach a debugger in order to further investigate problems that might occur with a worker process while you can configure the worker processes to run under an account with lower privileges than LocalSystem using the Identity tab. By changing the worker process identity, you can allow users to upload executables to the Web server under an account with low privileges, and ensure that it cannot do damage to the IIS server. Finally, the Health tab can be used to disallow use of an application, referred to as Rapid Fail Protection, in the event that the application experiences a configurable number of crashes in a configurable time period.
As you can see from Figure 1, the other core part of the IIS 6.0 architecture is the Web Administration Service (WAS). As the name implies, the WAS is responsible for configuring HTTP.SYS, and both starting on demand and configuring the worker processes. WAS is also responsible for enforcing the health-detection features incorporated into IIS 6.0, which works in two ways. First, the WAS periodically pings the worker processes to ensure that they are not locked up and still responding (although this can be configured through the Health tab, as shown in Figure 3). Second, WAS maintains a communication channel to each worker process, so it can quickly tell when a worker process abnormally terminates. In both cases, the W3SVC service can start another worker process in place of the "terminally ill" process. Interestingly, because HTTP.SYS queues incoming requests (the number of requests is configurable in the Performance tab) for each application pool, it can continue to accept requests and hold them until the W3SVC service starts up the new worker process. This allows uninterrupted access for the majority of users.
The combination of WAS and the worker processes ensures that no custom or third-party code runs in the same process as the functions internal to IIS. Obviously, this promotes the overall stability and robustness of IIS so that any malicious or buggy code cannot affect the core IIS functionality.