IIS 6 Administration

It turns out that everything you’ve learned so far about IIS 6 architecture is really only half the story. IIS 6 is a kind of chameleon that can change its colors to meet the needs of its environment, and it actually has two possible architectures that are quite different from one another. These architectures are referred to as the application isolation modes because they determine how applications are isolated from one another for greater reliability and scalability. The two application isolation modes of IIS 6 are as follows:

• Worker process isolation mode This is the main operating mode of IIS 6 and involves the core components we have been discussing so far, in the way I have described them. Everything I’ve said so far about IIS 6 architecture refers to its architecture when running in worker process isolation mode.

• IIS 5 isolation mode This secondary mode of operation employs a modified IIS 6 architecture designed to be backward compatible with applications developed specifically for the IIS 5 platform. If an application built for IIS 5 won’t run on IIS 6 in worker process isolation mode, you can run IIS 6 in IIS 5 isolation mode instead to support it.

Let’s look at these two modes in detail now to get the big picture.

Worker Process Isolation Mode

This is the primary mode of operation for IIS 6 and implements all of the new and enhanced architectural features we’ve discussed so far, including worker processes, application pools, health monitoring, demand start, rapid fail protection, and so on. Figure 2-10 shows the architectural big picture when IIS 6 is running in worker process isolation mode:

Figure 2-10: Big picture of IIS 6 architecture when running in worker process isolation mode

• User mode worker processes pull HTTP requests from the Kernel Mode HTTP Listener http.sys. Each application pool also has its own corresponding kernel mode queue in http.sys.

• Application pools may contain either single or multiple web applications and be serviced by either a single worker process or, in the case of a web garden, multiple worker processes. This means that applications can be isolated from each other in separate pools so that the failure of one application can be prevented from affecting other applications. Another way of saying this is that applications are isolated from each other by process boundaries.

• User-developed code such as ASP or ASP.NET applications and ISAPI extensions are loaded only into worker processes, not into IIS core components like inetinfo.exe or http.sys. This means core IIS processes can never be brought down by a failed user application.

• Application pools and their worker processes are managed by the new Web Administration Service (WAS).

• The FTP, NNTP, and SMTP Services and the XML metabase are managed by inetinfo.exe.

  Tip

  Although a crashed web application in IIS 6 will not affect the FTP, NNTP, and SMTP Services running in inetinfo.exe, the reverse is unfortunately not true. If something happens to bring down the FTP, NNTP, or SMTP Service, web applications can be adversely affected as well. The reason is that inetinfo.exe also manages the metabase, which contains the configuration information for (among other things) websites and applications running on IIS. Failure of FTP, for example, could bring down inetinfo.exe, which would bring to a halt all web applications running on the server. This single point of failure will probably be fixed in future versions of IIS. In the meantime, it might be best if IIS machines used for hosting mission-critical web applications were not also used to host FTP sites, NNTP discussion groups, or SMTP mail relay sites. In other words, offload these functions to a separate IIS machine for greater reliability.

To understand Figure 2-10 fully, I’ll walk you through the process of a client web browser requesting an ASP page from IIS 6:

1. The client sends the HTTP GET request.

2. The request is detected by http.sys, which verifies it as a valid request. If the request is invalid, http.sys returns the appropriate HTTP error code to the client.

3. http.sys checks the kernel mode response cache to see if the requested page has been cached from a recent request. If the response is in the cache, http.sys returns the cached response to the client. This happens very fast because everything takes place in kernel mode. Note that http.sys is capable of caching both static and dynamic content.

4. Http.sys routes the request to the appropriate kernel mode queue associated with the application pool for the ASP page being requested.

5. As soon as a thread becomes available, a worker process for the application pool pulls the request from the kernel mode cache. If there is currently no worker process servicing the application pool, http.sys notifies the WAS, which starts a worker process for the pool.

6. The ASP page is executed within the worker process using the ISAPI filter for the ASP script engine, which also runs within the worker process.

7. The worker process sends the response to http.sys, which caches it for future use and returns it to the client. http.sys may also log the action if IIS logging is enabled.

Worker process isolation mode is the recommended mode of operation when using IIS 6 because of its increased reliability, availability, and performance. For applications that break when run in this mode, however (such as applications developed for earlier versions of IIS), an alternate mode of operation can be used called IIS 5 isolation mode, which I’ll discuss next.

IIS 5 Isolation Mode

If applications developed for IIS 5 don’t run properly on IIS 6, you can make them run properly by running IIS 6 in a second application isolation mode called IIS 5 isolation mode. This mode of IIS 6 operation basically emulates the IIS 5 architecture to ensure backward compatibility for legacy applications to run on IIS 6. The architecture of IIS 5 isolation mode is quite different from that of worker process isolation mode, as can be seen from Figure 2-11.

Figure 2-11: Big picture of IIS 6 architecture when running in IIS 5 isolation mode

From an examination of Figure 2-11, you can determine the following architectural features of IIS 6 when running in IIS 5 isolation mode:

• The WWW Service process w3svc.dll, which runs in-process within a svchost.exe host process, pulls HTTP requests from the request queue of the Kernel Mode HTTP Listener http.sys. A single worker process within w3svc.dll acts as a process pool for running in-process web applications.

• Applications can alternatively be run out-of-process within dllhost.exe host processes.

  Note

  Note that in IIS 5 isolation mode there is only one kernel mode request queue servicing http.sys. This means all HTTP requests are routed through inetinfo.exe regardless of whether the requested applications are running in-process (within inetinfo.exe) or out-of-process (within dllhost.exe). This means that routing of HTTP requests is slower in IIS 5 isolation mode than in worker process isolation mode. If you want the best possible performance out of IIS 6, you must run it in worker process isolation mode.

Examples of applications that require IIS 6 to be running in IIS 5 isolation mode in order to function properly include the following:

• ISAPI applications that can be loaded multiple times and run concurrently

• ISAPI filters that perform read-raw data filtering

• Any applications that need to call processes located outside the application pool where the application resides

• Any application that needs to persist session state information (with the exception of ASP.NET applications)

  Note

  IIS 5 isolation mode is also sometimes known as compact mode or compatibility mode.

Comparison with IIS 5

If you compare the IIS 5 isolation mode of IIS 6 (Figure 2-11) with the earlier architecture of IIS 5 itself (Figure 2-5), you can see that in both cases the core inetinfo.exe process manages the IIS metabase; runs ISAPI filters and in-process ISAPI extensions; and manages the FTP, NNTP, and SMTP Services. In IIS 5 isolation mode, however, HTTP protocol support has been moved from inetinfo.exe (which used Winsock to manage HTTP requests in IIS 5) to the new kernel mode http.sys component of IIS 6, which is itself managed by the new WAS component of IIS 6. The actual operational differences are slight enough that any application designed to run on IIS 5 will run without problem on IIS 6 when IIS 5 isolation mode is being used.

When IIS 6 is running in IIS 5 isolation mode, it offers the same three application protection levels offered by IIS 5 itself: Low (IIS Process), Medium (Pooled), and High (Isolated). When you run a legacy IIS 5 application on IIS 6 in this mode, configure the application protection level to the same setting used on the downlevel Windows 2000 Server running IIS 5. An additional point to mention is that when IIS 6 is configured in IIS 5 isolation mode, applications running as either Medium (Pooled) or High (Isolated) will experience the same kind of performance hit such out-of-process applications experienced in IIS 5. This is due to the same issue of data marshalling that negatively impacted performance for these application protection levels in IIS 5. When IIS 6 is configured in worker process isolation mode, however, there is no such performance penalty because all applications and their associated ISAPI filters run in-process within a worker process w3wp.exe.

So the bottom line is, don’t run IIS 6 in IIS 5 isolation mode unless there’s absolutely no other way to get your applications working!

Comparison of IIS 6 Application Isolation Modes

Now that we’ve looked in detail at the two application isolation modes in IIS 6, let’s make sure you understand them by comparing their features at the process level. Table 2-1 lists the key architectural features of IIS 6 in each mode and the corresponding process managing or implementing each feature.

Another difference between the two application isolation modes of IIS 6 is that certain features are not available when running in IIS 5 isolation mode:

• Health detection

• Process recycling

• Processor affinity

• Rapid fail protection

• Web gardens

Availability of Modes

The default application isolation mode for IIS 6 depends on whether installation or upgrade has been performed, specifically,

• New (clean) installations of Windows Server 2003 where the IIS 6 component has been selected will result in IIS 6 being installed to run by default in worker process isolation mode.

• Upgrading from Windows NT Server (IIS 4) or Windows 2000 Server (IIS 5) to Windows Server 2003 will result in IIS 6 being installed to run by default in IIS 5 isolation mode.

I’ll discuss IIS 6 deployment further in the next chapter, “Planning Deployment.”

Switching Modes

You can also switch between the two application isolation modes of IIS 6, but this can have certain effects. For example, if you switch from IIS 5 isolation mode to worker process isolation mode, all of your isolated out-of-process web applications will be moved into a single application pool (the default application pool) that is created when IIS 6 is installed. You can then create additional application pools, however, and move your applications to these pools to increase reliability. Switching application isolation modes can be done using a simple check box on a property sheet that’s accessed by the Internet Information Services console tool, as you’ll see in Chapter 9. You can also switch application isolation modes from the command-line using ADSI as you’ll see in Chapter 11.