IIS 6 Administration

Now that we’ve reviewed in detail how the architecture of IIS has evolved from versions 1 through 5, it’s time to move on and examine the inner workings of version 6, the latest incarnation of IIS. I’ll do this by first providing an overview of the differences between version 6 and the previous version 5, and then going into detail about the components and operation of version 6.

Differences from IIS 5

First, here is a summary of the key differences between IIS 6 and earlier versions:

• Handling of HTTP requests has been moved from the main inetinfo.exe process directly into the kernel for better performance.

• Two new application isolation models are supported: worker process isolation mode (totally new), which fully isolates all user-developed application code from the core IIS services, and IIS 5 isolation mode, which is provided for backward compatibility with older applications designed for IIS 5.

• Support for multiple application pools is now included, with each pool being independently configurable.

• The WWW Service (W3SVC) has been restructured to include a new config- uration and process management portion called the Web Administration Service (WAS).

The IIS 6 architecture also supports other enhanced features including processor affinity, health monitoring, web gardens, demand start, idle timeout, rapid-fail protection, recycling of worker processes, XML metabase, and so on. Many of these features are discussed in the following sections, while some (like the XML metabase) are explained elsewhere in this book.

Let’s now look at each of these new features in detail, building your knowledge of the IIS 6 architecture block by block.

Kernel Mode HTTP Listener (http.sys)

Earlier versions of IIS had their architecture built around the core inetinfo.exe process. This process contained the IIS Admin Services plus four protocol services dependent upon IIS Admin:

• W3SVC, the World Wide Web Publishing Service

• MSFTPSVC, the FTP Publishing Service

• NNTPSVC, the Microsoft NNTP Service

• SMTPSVC, the Microsoft SMTP Service

Incoming HTTP requests were received by the IIS Admin Service and handed off to either

• W3SVC, if the request was for either static HTML content or dynamic content from a web application running in-process (within inetinfo.exe).

• A dllhost.exe helper process, if the request was for dynamic content from a web application running out-of-process, either as an isolated process in IIS 4 and 5 or as a pooled process in IIS 5.

In other words, the core inetinfo.exe process functioned as

• Listener Waiting for incoming HTTP requests

• Router Forwarding such requests to the appropriate protocol service or helper process

The problem with earlier versions of IIS was that inetinfo.exe, which handled these two functions, ran as a pageable user mode process. The term user mode is one of two processor modes in which code can execute; the other is kernel mode. Because user mode processes can contain user-developed code, which may be buggy, a single misbehaving web application could bring inetinfo.exe down and thus prevent incoming HTTP requests from being received and handled.

To overcome this problem, Microsoft has moved the HTTP listening and routing functions of IIS 6 from the user mode inetinfo.exe process to a kernel mode process called the Kernel Mode HTTP Listener. This new component is implemented as a kernel mode device driver called http.sys that is part of the TCP/IP networking subsystem of Windows Server 2003. Architecturally, http.sys sits as a network driver on top of TCP and listens for HTTP requests that want to connect to IP addresses and port numbers used by websites running on IIS. In other words, http.sys is not really part of IIS at all, it’s part of the TCP/IP stack of Windows Server 2003. Its main purpose is to be used by IIS for handling HTTP requests, but it also fulfills several other functions including caching HTTP responses in kernel mode, managing TCP connections, implementing connection limits and time-outs, managing bandwidth throttling, and handling text-based logging for the WWW Publishing service.

Modifying the architecture of IIS in this fashion has several significant benefits:

• IIS performance is improved because kernel mode processes execute with a higher level of priority than user mode processes. In essence, http.sys acts to tune IIS throughput by speeding up response to incoming HTTP requests.

• IIS reliability is improved because http.sys contains no user-developed code and thus cannot be crashed by a buggy web application.

• IIS responsiveness is improved because http.sys can continue to receive and queue HTTP requests even when the applications for which it is queuing these requests crashes.

Kernel mode and user mode refer to the two levels of privilege in which routines can run on the Windows Server 2003 platform. Applications running in kernel mode have full access to hardware and to system data, while those running in user mode have nonprivileged access to system data and no direct hardware access. Kernel mode applications are generally components of the operating system itself, and they run in the highly privileged ring 0 mode of the Intel x86 processor architecture. User mode applications include operating system components that display a user interface as well as programs developed by users, and they run in the less-privileged ring 3 mode. IIS includes components running in both kernel and user mode.

The fact that inetinfo.exe is pageable means that having insufficient physical memory (RAM) on an IIS machine can significantly affect performance. If there is insufficient RAM, IIS may page part of inetinfo.exe to disk, which can severely affect the response of web applications. In IIS 6, insufficient memory can result in http.sys queues filling up and requests being dropped, so ensure that your IIS machines have enough RAM to keep the entire inetinfo.exe process in memory at all times. Use the Performance console to monitor the size of the working set and number of page faults per second for inetinfo.exe to determine whether you have enough RAM installed.

In addition to listening for and parsing incoming HTTP requests and routing (forwarding) them to the appropriate worker process for further processing, http.sys does a few other important things:

• It queues such requests for processing by IIS. Each application pool in IIS has a corresponding in-memory kernel mode queue associated with it, and http.sys routes requests to these queues where they can wait for user mode worker processes to service these requests. I’ll talk more about worker processes and application pools in the sections “Worker Processes” and “Application Pools,” later in this chapter.

• It manages all TCP connections, both setup and tear-down, for incoming HTTP requests and outgoing HTTP responses.

• It caches HTTP responses using a kernel mode cache so that frequently requested content can be served without needing to switch from kernel mode to user mode and invoke inetinfo.exe. http.sys can cache HTTP responses for both static and dynamic content. Kernel mode caching is discussed further later in this chapter.

• It handles other IIS functions previously performed by inetinfo.exe, including IIS logging services and quality of service (QoS) functions like bandwidth throttling, connection limits, and connection timeouts. IIS logging is discussed in more detail in the section “Logging,” later in this chapter.

Note that http.sys does not actually process HTTP requests; it simply routes these requests to the appropriate IIS worker process, receives HTTP responses from these processes, and forwards them back to the requesting client. The only exception to this is if the response can be retrieved from its internal kernel mode cache, in which case http.sys appears to be “processing” the request and returning a response.

Let’s now look at this kernel mode queuing by http.sys in a bit more detail.

Kernel Mode Queuing

Kernel mode queuing will continue even if the web applications that HTTP requests are being queued for crashes. That’s really the purpose of queuing, of course: to allow requests to be collected until they can be serviced. For example, a print job is queued (spooled) so that if the printer runs out of paper, the job can be held until the situation is corrected. With IIS 6, this queuing of HTTP requests will continue until each queue is full (the size of these queues can be configured by the administrator). Each application pool (pool of web applications serviced by a dllhost.exe process) has its own separate queue, and http.sys routes incoming requests to the appropriate pool (see Figure 2-7). The advantage of these kernel mode queues is that pending HTTP requests are not lost when a web application crashes on IIS 6, and normally IIS 6 will recover and restart the application so queued requests will not be lost (the client may not even notice that the application crashed, just that it took a little longer to respond than normal).

Figure 2-7: http.sys forwards incoming HTTP requests to a queue to await processing by an application pool.

IIS Admin Service

If the HTTP listening and routing functions have been removed from the main IIS process inetinfo.exe in IIS 6, what functions still remain for this process? In previous versions, inetinfo.exe has contained both the IIS Admin Service and protocol services like the WWW and FTP Services. But with IIS 6, this model has changed: the IIS Admin Service now handles everything IIS does that is not connected with the Web. In other words, in IIS 6 the IIS Admin Service is responsible for FTP, NNTP, and SMTP, but not HTTP. When you create an FTP site on IIS 6, the IIS Admin Service handles the configuration and operation of that site. But if you create a website, a different service called the Web Administration Service (WAS) is employed instead of IIS Admin.

An important consequence of the fact that the IIS Admin Service is no longer directly associated with the WWW service in IIS 6 is that in-process web applications are no longer allowed. Remember that in IIS 5 you could run web applications either in-process (within inetinfo.exe, which hosts the IIS Admin Service) or out-of-process (either as a singled pooled process or multiple isolated processes, both running within a dllhost.exe proxy process). Well, in IIS 6 things have changed: web applications can no longer run in-process, that is, in the same memory space as inetinfo.exe. All web applications instead now run out-of-process as pooled processes called application pools. Actually, to be more correct, IIS 6 usually runs in this fashion, but as you’ll see there is an exception when IIS 6 is run in a special mode called IIS 5 isolation mode. We’ll talk more about the two IIS 6 modes in the section entitled “IIS 6 Application Modes” later in this chapter.

You can see which processes are associated with each IIS protocol by using the Services console in Administrative tools. Open the Services console and double-click IIS Admin to open its properties sheet, and you'll see that the executable associated with this service is inetinfo.exe, which resides in the System32\inetsrv\ directory. Do the same with the FTP Publishing Service, and you'll see that the associated executable is again inetinfo.exe. The same is true for the Network News Transfer Protocol (NNTP) and Simple Mail Transfer Protocol (SMTP) Services. But if you open the properties sheet of the World Wide Web Publishing Service, you'll see that the corresponding executable is svchost.exe instead. svchost.exe was introduced in Windows 2000 and Windows XP as a generic host process for those kinds of services that run from dynamic link libraries (DLLs) instead of from executable files. In the case of the WWW Service, the associated executable is listed as svchost -k iissvcs. Here iissvcs indirectly identifies the DLL that runs the WWW Publishing Service, as you'll see in the next section.

Web Administration Service (WAS)

If the IIS Admin Service (which lives within inetinfo.exe) is no longer responsible for the creation and operation of websites on IIS 6, which service handles this function? The answer is the Web Administration Service (WAS), a new component in IIS 6. This new service has two components:

• Configuration Manager Responsible for interacting with the metabase to store or retrieve website configuration information when needed. It is also responsible for initializing the namespace routing table for the Kernel Mode HTTP Listener (http.sys) at startup—it creates one entry in the http.sys routing table for each application pool so queued HTTP requests can be routed to the appropriate pool. Also, as new pools are created for new web applications, the WAS Configuration Manager notifies http.sys to update its routing table accordingly. http.sys needs this information so that if an application fails, it can be restarted; and if an application pool requires an additional worker process to handle the load, it can create one on demand.

• Application Pool Manager Responsible for managing the worker processes associated with IIS application pools. These include starting, stopping, restarting, and recycling worker processes, and monitoring their health and maintaining their configuration and how they interact with their kernel mode queue associated with http.sys.

The WAS is an essential component of the WWW Publishing Service (W3SVC) and is implemented, like the IIS Admin Service, in user mode. WAS is not responsible for running any user-developed code, however, such as a web application. Instead, web applications are run within separate processes called worker processes, which I’ll discuss next.

As I mentioned in the Note in the preceding section, unlike the IIS Admin Service, which runs as an executable (inetinfo.exe), the WAS (and hence W3SVC itself) runs instead as a DLL within a host process called svchost.exe. You saw earlier that the associated executable for the WWW Service was svchost.exe -k iissvcs and that the actual DLL for the WAS could be determined from this parameter iissvcs. You can do this by examining the Registry. Select the following key:

HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Svchost

The values under this key show the names of the various groups of services that can run within svchost.exe host processes on Windows Server 2003. (If you open Task Manager and select the Processes tab, you may see several instances of svchost.exe running at any given time, where each instance represents a service or group of services that are run as DLLs instead of executables.) Find the value named iissvcs and note that the data for this value reads w3svc. Now go to the following key:

HKLM\System\CurrentControlSet\Services\W3SVC

Select the Parameters key under this and open the value named ServiceDLL. The data for this value is as follows:

%systemroot%\System32\inetsrv\iisw3adm.dll

You’ve discovered that the DLL for the WAS is named iisw3adm.dll and is located in the \ inetsrv directory, where inetinfo.exe is also found. For more information on svchost.exe, see Knowledge Base article 314056 on support.microsoft.com.

Worker Processes

I mentioned that the WAS is responsible for managing worker processes and that worker processes are associated with application pools on IIS 6, but I haven’t explained either of these terms yet. I’ll do that now.

In IIS 6, all user-developed application code runs in special user mode processes called worker processes. These worker processes act as host processes within which user-developed code such as ASP applications can run. They are called “worker processes” because their job (work) is to process user requests received from kernel mode http.sys queues and return the results (either a static or dynamic page) to the user (again via http.sys).

The executable w3wp.exe implements an instance of a worker process, and IIS 6 typically has multiple worker processes running at any given moment, each servicing different applications or pools of applications. A worker process can host ISAPI applications and filters, ASP applications, CGI applications, and static content. ISAPI filters and extensions are loaded into w3wp.exe via a web service DLL, which also handles authentication and authorization for applications running within the worker process.

Worker processes are themselves controlled by the WAS, which I just discussed. The WAS manages the health of worker processes and can restart or recycle them when needed. This “health monitoring” feature of IIS 6 works by having the WAS periodically ping each worker process to determine whether they are active (can respond to the ping) or blocked (either crashed or too busy to respond). When a worker process becomes blocked, the WAS automatically terminates the worker process and starts a new one to replace it. This might happen, for example, if an ISAPI filter within the worker process causes a memory access violation, causing the worker process to crash. Should this happen, the WAS automatically starts a new worker process to replace the failed one. This is certainly better than the old IIS 5 model, where ISAPI filters typically ran in-process within inetinfo.exe and their failure resulted in IIS going down completely.

The purpose of these worker processes is thus to ensure the greatest possible reliability for IIS 6 as a web application hosting platform. This is accomplished by enabling user-developed applications to be separated both from each other via process boundaries and from core IIS code such as inetinfo.exe and http.sys. Application isolation is ensured because each worker process can service only a single application pool, and each worker process has its own corresponding kernel mode queue within http.sys.

The role of worker processes in this is illustrated in Figure 2-8. An incoming HTTP request is received by http.sys and queued in kernel mode until the worker process for the application called can pull the request from the queue and process it. The results are returned by the worker process to http.sys, which caches the response (in case it is requested again shortly) and sends it to the requesting client.

Figure 2-8: A worker process acts as a host process within which a web application or ISAPI filter can run.

Processor Affinity

An additional feature of worker processes is that on symmetric multiprocessing (SMP) machines an individual worker process can be assigned to a specific CPU for processing. This feature is known as processor affinity and makes IIS 6 a powerful platform for running large mission-critical web database applications. Processor affinity for IIS 6 applications can be configured using Active Directory Services Interface (ADSI) or Windows Management Instrumentation (WMI).

Application Pools

The final piece of the puzzle for IIS 6 architecture is the application pool, which is essentially one level of abstraction higher than worker processes. Whereas a worker process is a host process named w3wp.exe within which user-developed web application code can run, an application pool consists of the following:

• One kernel mode http.sys request queue

• One or more worker processes (instances of w3wp.exe)

Combining together the ideas of worker processes and application pools, there are three possible configurations for running applications on IIS 6:

• An application pool consisting of one worker process hosting a single web application isolated from all other applications by process boundaries (see Figure 2-9A). This corresponds to the concept of an out-of-process application in IIS 4 or an isolated process in IIS 5, but the performance is much improved in IIS 6 because all user-developed code such as ASP pages or ISAPI extensions run in-process within the worker process servicing the pool, eliminating the need for processor context changes from user mode to user mode, which are inherently slow to implement.

  Figure 2-9: Examples of different types of application pools supported by IIS 6

• An application pool consisting of one worker process hosting two or more web applications (see Figure 2-9B). This is the analog of default Medium (Pooled) process setting in IIS 5 but has no corresponding analog in IIS 4. This approach to using application pools is the default in IIS 6, where multiple ASP applications and ISAPI extensions or filters are run within the same application pool. Each application running within the pool shares the worker process servicing the pool (pulling HTTP requests from the kernel into the pool and returning responses to http.sys). As you’ll see in the section called “Application Pools” later in this chapter, you can create as many of these application pools as desired, something you couldn’t do with IIS 5, which allowed only one pooled process to run.

• An application pool consisting of multiple worker processes hosting one or more web applications (see Figure 2-9C). This configuration is new to IIS 6 and is referred to by the new name of web garden. A web garden is a special feature of IIS 6 that allows multiple worker processes to service a single application pool. In other words, a web garden is an application pool serviced by several worker processes, as opposed to the default single worker process per pool. The name “web garden” is derived from “web farm,” which refers to multiple web servers running a single application; but in the case of web gardens, this all takes place on a single physical machine. When an incoming HTTP request arrives for an application running in a web garden, the kernel mode HTTP listener (http.sys) decides on which worker process (that is, which particular instance of w3wp.exe) within the web garden to forward the request to. Web gardens increase the reliability of IIS 6 even further by ensuring that if a worker process servicing an application becomes bogged down, the load can be taken up by the other worker processes in the garden. Web gardens can be configured for application pools that have either a single application running in them (for enhanced performance and fault tolerance) or multiple applications (for better reliability and to prevent application thread blocking from occurring).

The default type of application pool on IIS is one that has a single worker process servicing it. In other words, web gardens must be planted and grown, they don’t just spring up by themselves!

As I already mentioned, a major difference between IIS 5 and the current version is that in IIS 6 there can be multiple application pools running on a single machine, while in IIS 5 there was only one pooled process. In addition, each application pool in IIS 6 can be configured differently, and applications can easily be moved from one pool to another. When you install IIS 6, a default application pool is created that you can use to run as many applications as you wish, or you can create additional pools to isolate groups of applications (or individual applications) from one another. You can also rename the default pool if desired.

Application pools are a great advantage in IIS 6 because they increase reliability by allowing sites to be grouped together and isolated from other sites. For example, should one application within a pool crash, the only applications affected are others within that pool—applications in other pools remain unaffected. The application pool model is also less memory intensive than the process isolation model of IIS 5 and allows many more (possibly thousands) of sites to be hosted on a single IIS 6 machine with good performance resulting, thus greatly increasing the scalability of IIS over previous versions. Finally, application pools simplify the administration of web applications on IIS 6 by allowing configuration settings to be applied simultaneously to a group of web applications residing within the same pool.

An exception to the application isolation offered by having different applications run in different application pools can exist with regard to COM+ objects. Normally a COM+ object will be written to run in-process. Such a COM+ object can run as a component of multiple applications hosted by multiple pools. If the COM+ object fails in one application pool, other applications in different pools will remain unaffected. If the COM+ object is a singleton (designed to run as a single instance object), however, then all worker processes hosting this object will be affected and all applications using this object will fail, regardless of which pool they run in. In this case, the best solution from the administrator’s point of view is to put all web applications that use this singleton COM+ object in the same application pool and disable overlapped recycling because of the concurrency issues. COM+ is pretty esoteric stuff and mainly of interest to developers. I won’t go into it further in this book except to mention that the main thing for developers to remember when creating COM+ objects for IIS applications is that they need to be designed to run in-process as local servers.

Application pools are managed by the same WAS that manages the lifecycle of worker processes associated with these pools. These settings for application pools and worker processes are configurable in IIS 6 and include a number of advanced features. Let’s discuss these briefly while we’re on the topic of application pools.

Demand Start

The new Demand Start feature of IIS 6 allows worker processes to be started to service an application pool when the first HTTP request for an application within the pool is received. This means valuable memory is not used by pools until the first request directed toward an application in the pool is received. Demand Start also allows additional worker processes to be started to serve the pool should this be required. This is a big improvement over earlier versions of IIS and means that more sites can be hosted on a single machine. It also speeds up the startup and shutdown time for a machine hosting large numbers of sites because worker processes don’t need to be instantiated during startup, they can instead be started when the first HTTP request is received for the applications they service.

Demand Start also means that IIS 6 manages its processor, memory, and disk resources much better than previous versions. It does this by allocating resources as needed when HTTP requests are received rather than pre-allocating them at startup. Using Demand Start, an IIS machine can start up with numerous applications ready to run but not a single worker process running. As soon as an incoming HTTP request arrives for an application, IIS allocates the resources to start a worker process for the application.

Demand Start is managed by the WAS component of IIS 6 and, together with the new Idle Timeout feature discussed next, makes IIS 6 a much more resource-efficient application-hosting platform than earlier versions.

Idle Timeout

If a worker process servicing an application pool has been idle for a specified amount of time, the WAS can automatically shut down the process, saving valuable memory on the machine. This means IIS 6 can actually tune itself to utilize only those memory and processor resources needed to service websites and applications that are actually actively being used by clients.

Taken together, the Demand Start and Idle Timeout features mean that IIS 6 is much more efficient in its use of memory resources than previous versions, which enhances the scalability and performance of the platform. Idle Timeout can cause problems in certain situations, however, such as when used in conjunction with process recycling discussed next.

Recycling

Sometimes a web application developed by a user will contain faulty code leading to conditions like memory leaks or violations. It may not be feasible to correct this situation (the coder may be on vacation). In previous versions of IIS, the web server had to be rebooted periodically to keep the application up and running. In IIS 6, however, this can be accomplished through recycling worker processes associated with the pool instead of manually rebooting the server.

Recycling (also called process recycling) is managed in IIS 6 by the WAS, which is the parent process of all worker processes running on the machine. Recycling is accomplished by configuring the pool so that its worker processes are scheduled to restart periodically whether the application has failed or not. This can be done on the basis of settings like the elapsed time running, a specific scheduled time of day, the number of HTTP requests received by the pool, virtual memory growing beyond specified limits, or manually on demand. When a worker process is recycled, the old process is notified to shut down, after which a brief period of time is allowed for any remaining requests in the queue to be serviced (this wait period is configurable). Then a new worker process spins up (that is, is started) to take the place of the old. The new process starts before the old shuts down, so there is no interruption in service from the client’s viewpoint. If the old process doesn’t respond to the shutdown command, it is forcibly terminated after a specified time interval. This type of recycling is called Overlapped Recycle because the new process is stopped before the old one is terminated. It is also possible to configure recycling so that overlap doesn’t occur, where the old process is first terminated and then a new one is started to replace it.

It’s generally better to use overlapped recycling because it ensures no interruption of service from the client’s perspective. However, in some instances, overlapped recycling can cause concurrency issues from multiple instances of the same ASP or ISAPI application running simultaneously, a condition known as multi-instancing. If you experience problems running an application with overlapped recycling enabled, try disabling this feature to see if the problem disappears. Alternatively, you can ask your developer to recode the application so that it can properly handle a multi-instanced execution environment, but this may be more trouble than it’s worth for older applications. A typical situation where this problem can arise is when a custom logging module is included as part of an application.

Idle Timeout together with recycling can cause problems for web applications like ASP applications where Session objects are used for storing state information between page views. In this scenario, the worker process times out, shuts down, and state information is lost and not transferred to the new process started by recycling. From the administrator’s point of view, the way around this is to disable the idle timeout and process recycling features for the application pool under consideration. An alternative would be to run IIS 6 in IIS 5 isolation mode (discussed later in the chapter in the section “IIS 5 Isolation Mode”), but this is a poor solution because it entails a performance hit. From a developer’s viewpoint, however, the workaround is to modify the application so that it persists such state information externally, for example, within an XML-formatted text file or SQL database. An alternative for the developer is to use the enhanced Session Service of ASP.NET, but discussion of this is beyond the scope of this book.

Orphaning

I mentioned earlier that the WAS periodically monitors the health of worker processes associated with application pools. Should a worker process be found unresponsive, the WAS normally forces termination of the process and starts a new process to replace it. However, IIS 6 can be configured instead to leave the unresponsive worker process running while it starts a new process to take over the load. This is accomplished by enabling a feature called orphaning, which is used mainly in a development context. For example, a debugger could be configured to connect to an orphaned process to determine what went wrong, since shutting down the offending process would prevent the developer from debugging the problem.

Rapid Fail Protection

Sometimes things go very wrong with applications, and they may be so buggy that the pool hosting them repeatedly shuts down. The rapid fail protection feature of IIS 6 allows pools to be configured so that if frequent multiple failures occur (more than a threshold number), the pool is switched to an out-of-service mode instead of being restarted. In this scenario, http.sys returns an HTTP 503 Service Unavailable message to clients making requests to applications in the pool. Administrators can manually produce the same effect by stopping the application pool using the Management console. You’ll see how to do this later in Chapter 8, “Creating and Configuring Applications.”