IIS Modes of Operation

As a developer, it is important to understand the processing differences between modes of operation because it affects process and thread identity.

IIS Isolation Modes

IIS 6.0 runs in one of two distinct modes of operation, which are called application isolation modes: worker process isolation mode, and IIS 5.0 isolation mode which is almost identical to the process model of IIS 5.1 and earlier.

Worker process isolation mode takes advantage of the redesigned architecture for IIS 6.0 and uses the worker process core component.

IIS 5.0 isolation mode is provided for applications that depend on specific features and behaviors of IIS 5.1 or earlier. The isolation mode is specified by the IIs5IsolationModeEnabled metabase property in IIS 6.0. On previous versions of IIS, this is the only mode.

The IIS application isolation mode that you choose impacts performance, reliability, security, and feature availability. Worker process isolation mode is the recommended mode of operation for IIS 6.0 because it provides a more robust platform for applications.

Although worker process isolation mode offers increased isolation, reliability, availability, and performance, some applications may have compatibility issues when running in this mode. If you encounter compatibility problems, use IIS 5.0 isolation mode on IIS 6.0.

When deciding which isolation mode to use on IIS 6.0, consider the following:

• Unless you are required to use IIS 5.0 isolation mode due to a specific compatibility issue, use worker process isolation mode on IIS 6.0.

• Web sites with static content and simple Microsoft Active Server Pages (ASP) applications should be able to run with little or no modification in worker process isolation mode.

• If applications are running correctly on IIS 5.0, they should run correctly in IIS 5.0 isolation mode.

Worker Process Isolation Mode

Worker process isolation mode leverages all of the new IIS 6.0 core components. Using worker process isolation mode enables application pooling, recycling, and health detection features.

With IIS 6.0 running in worker process isolation mode, you can group Web applications into application pools. Application pools allow specific configuration settings to be applied to groups of applications, and the worker processes servicing those applications. Any Web directory or virtual directory can be assigned to an application pool.

Every application within an application pool shares the same worker process. Because each worker process operates as a separate instance of the worker process executable, W3wp.exe, the worker process that services one application pool is separated from the worker process that services another. This ensures that if a Web application fails, it will not affect the applications that are running in other application pools. This architecture makes IIS very reliable because the World Wide Web Publishing Service (WWW service), IIS Admin service, and HTTP.sys are able to stay up and running continually, despite any service interruptions that can occur in a worker process.

A worker process is an application that runs in user mode. Its typical roles include processing requests to return a static page, invoking an Internet Server API (ISAPI) extension or filter, or running a Common Gateway Interface (CGI) handler. A worker process is physically implemented as an executable file named W3wp.exe and is controlled by WWW Service Administration and Monitoring. By default, worker processes run as NetworkService, which has the strongest security (least access) that is compatible with the functionality required. Worker processes use HTTP.sys for sending requests and receiving responses over the Web. The worker process also runs application code, such as Microsoft ASP.NET applications. Depending on how IIS is configured, there can be multiple worker processes running, serving different Web applications concurrently. This design separates applications by process boundaries, and it helps achieve maximum Web server reliability.

For more information about migrating applications, see the IIS Deployment Guide.

IIS 5.0 Isolation Mode

IIS 5.0 isolation mode ensures compatibility for applications that were developed for IIS 5.1 or earlier. The request processing of IIS 6.0 running in IIS 5.0 isolation mode is nearly identical to the request processing in IIS 5.0. In IIS 5.0 isolation mode, application pools, recycling, and health detection features are not available.

In IIS 5.0 isolation mode on IIS 6.0, HTTP.sys is used in the same way as it is in worker process isolation mode. The only exception is that it routes requests only to a single request queue that is maintained by the WWW service. Depending on how the isolation mode is configured (either in-process, pooled, or out?of?process) the request will be processed in either Inetinfo.exe or DLLHost.exe.

IIS administrators can either run applications in the same server process as IIS, in a pooled process, or they can isolate the application by running it in an isolated process, which is particularly helpful during development and testing. When a new application is created, it is added to the pooled process by default. A pooled process provides superior protection for the server without the overhead involved in maintaining a large number of isolated processes.

IIS 4.0 and earlier: Pooled process isolation is not available.

Isolation Mode Defaults

When you install IIS 6.0 on a computer that does not have a previous version of IIS installed, the isolation mode is automatically set to worker process isolation mode. If you upgrade from a previous version of IIS, the isolation mode is set to IIS 5.0 isolation mode, and all process isolation (in-process, pooled process, out-of-process applications) remain unchanged.

For more detailed information about IIS 6.0 Architecture, see the "IIS 6.0 Architecture" topic in the IIS User Documentation.

For more detailed information about features and benefits of IIS 6.0 Worker Process Isolation Mode, see the "Web Application Isolation" topic in the IIS User Documentation.