Understanding the Services and Processing Architecture

A strong understanding of the services and processing architecture used by IIS 7.0 is essential to your success as an administrator. As you'll see in this section, IIS 7.0 is very different from its predecessors, and the differences you'll learn about mean that you manage core IIS 7.0 features in fundamentally different ways. Although this section provides an initial discussion of applications and application pools ,Essential IIS Services and Processes

Windows services and processes are other areas where Windows and IIS are tightly integrated. Table 3-3 provides a summary of key services that IIS uses or depends on. Note that the services available on a particular IIS server depend on its configuration. Still, this is the core set of services that you'll find on most IIS servers.

Table 3-3. Essential IIS Services

Display Name	Service Name	Description	Default Startup Type	Log On As	Default Recovery	Dependencies
Application Host Helper Service	Apphostsvc	Provides configuration history services and app pool account mapping for file and directory access locking.	Automatic	Local System	Restart the service	None
ASP.NET State Service	aspnet_state	Provides support for out-of-process session state management for ASP.NET. Out-of-process state management ensures that the session state is preserved when an application's worker process is recycled. IIS uses this service only when you set the Session State mode to State Server or SQL Server. Otherwise, IIS does not use this service.	Manual	Network Service	Restart the service	None
FTP Publishing Service	MSFTP-SVC	Provides services for transferring files by using FTP. If the server isn't configured as an FTP server, the server doesn't need to run this service. In a standard installation of IIS 7.0, when you install FTP, this service is, by default, configured for manual startup only.	Manual	Local System	Take no action	IIS Admin Service
IIS Admin Service	IISAD-MIN	Allows administration of IIS 6.0–related features, including the metabase. If the server doesn't need backward compatibility, the server doesn't need to run this service.	Automatic	Local System	Run iisreset.exe	HTTP, RPC, Security Accounts Manager
Web Management Service	WMSVC	Enables remote and delegated management of IIS using IIS Manager. If a server is locked down so it can be accessed locally only, the server doesn't need to run this service.	Automatic	Local Service	Restart the service	HTTP
Windows Process Activation Service	WAS	Provides essential features for messaging applications and the Microsoft .NET Framework, including process activation, resource management, and health management. This service is essential for IIS.	Automatic	Local System	Run iisreset.exe	RPC
World Wide Web Publishing Service	W3SVC	Provides essential services for transferring files by using HTTP and administration through the IIS Manager. This service is essential for IIS.	Automatic	Local System	Take no action	HTTP, Windows Process Activation Service

As the table shows, the World Wide Web Publishing Service and Windows Process Activation Service provide the essential services for IIS 7.0. Management of the Web service and Web applications is internalized. The Web Administration Service component of the Web Service Host is used to manage the service itself. Worker processes are used to control applications, and no Internet Server Application Programming Interface (ISAPI) applications run within the IIS process context.

IIS Worker Process Isolation Mode

Worker Process isolation mode is the standard processing mode for Web sites and Web applications. This mode allows sites and applications to:

• Recycle worker threads

• Monitor process health

• Use advanced application pooling configurations

• Take advantage of other IIS 7.0 features

The World Wide Web Publishing Service and Windows Process Activation Service provide the essential services for IIS 7.0. From a high level, the standard IIS 7.0 operating mode works as depicted in Figure 3-1. Service Host processes control all Web resources running on a server. Starting, pausing, or stopping the World Wide Web Publishing Service affects all Web sites on the server. It doesn't directly affect the Service Host. Instead, Windows Server uses an intermediary to control the Service Host for you. For non-Web services, this intermediary is the Inetmgr.exe process. A single instance of Inetmgr.exe is used to manage Web sites and Web applications.

Management of the Web service and Web applications is internalized. The Web Administration Service component of the Web Service Host is used to manage the service itself. Worker processes are used to control applications, and no ISAPI applications run within the IIS process context.

Worker processes are used in several ways:

• Single worker process—single application Here a single worker process running in its own context (isolated) handles requests for a single application as well as instances of any ISAPI extensions and filters the application's need. The application is the only one assigned to the related application pool.

• Single worker process—multiple applications Here, a single worker process running in its own context (isolated) handles requests for multiple applications assigned to the same application pool as well as instances of any ISAPI extensions and filters the applications' needs.

• Multiple worker processes—single application Here, multiple worker processes running in their own context (isolated) share responsibility for handling requests for a single application as well as instances of any ISAPI extensions and filters the application's needs. The application is the only one in the related application pool.

• Multiple worker processes—multiple applications Here, multiple worker processes running in their own context (isolated) share responsibility for handling requests for multiple applications assigned to the same application pool as well as instances of any ISAPI extensions and filters the applications' needs.
  

The standard operating mode ensures that all sites run within an application context and have an associated application pool. The default application pool is DefaultAppPool. You can also assign sites and applications to custom application pools.

Each application or site in an application pool can have one or more worker processes associated with it. The worker processes handle requests for the site or application.

You can configure application pools to manage worker processes in many ways. You can configure automatic recycling of worker threads based on a set of criteria such as when the process has been running for a certain amount of time or uses a specific amount of memory. You can also have IIS monitor the health of worker threads and take actions to recover automatically from failure. These features might eliminate or reduce your dependence on third-party monitoring tools or services.

You can also create a Web garden in which you configure multiple worker processes to handle the workload. Applications configured using this technique are more responsive, more scalable, and less prone to failure. Why? A Hypertext Transfer Protocol (HTTP) listener, called Http.sys, listens for incoming requests and places them in the appropriate application pool request queue. When a request is placed in the queue, an available worker process assigned to the application can take the request and begin processing it. Idle worker processes handle requests in first-in, first-out (FIFO) order.

Worker processes can also be started on demand. If there are unallocated worker processes and no current idle worker processes, IIS can start a new worker process to handle the request. In this way, resources aren't allocated until they're needed, and IIS can handle many more sites than it could if all processes were allocated on startup.

Understanding and Using IIS Applications

You can configure Web sites to run several different types of applications, including:

• Common Gateway Interface (CGI) programs.

• Internet Server Application Programming Interface (ISAPI) applications.

• ASP.NET applications using managed code.

CGI describes how programs specified in Web addresses, also known as gateway scripts, pass information to Web servers. Gateway scripts pass information to servers through environment variables that capture user input in forms in addition to information about users submitting information. In IIS 7.0, standard CGI is implemented through the CgiModule and multi-threaded CGI is implemented through the FastCgiModule. The CgiModule has a managed handler that specifies that all files with the .exe extension are to be handled as CGI programs.

The way CGI programs are handled is determined by the way you've configured the CGI feature within IIS. By default, CGI is disabled. When you enable CGI, the CgiModule is the default handler for .exe programs. You can modify the handler configuration for .exe programs to use the FastCgiModule. This configuration is useful if you've installed the PHP Hypertext Preprocessor (PHP) on your IIS server and want to use it. Once you've configured the server to use FastCgi for .exe programs, you should add handler mappings for PHP-related file extensions and configure these mappings so that they use the PHP executable, such as Php-cgi.exe. For example, you could add mappings for *.php and *.php5. Your IIS server would then process files with the .PHP and .PHP5 extensions through Php-cgi.exe.

In IIS 7.0, ISAPI is implemented using two modules, IsapiModule and IsapiFilterModule. The IsapiModule makes it possible to use ISAPI applications and ISAPI extensions. In the IIS server core, several components rely on handlers that are based on ISAPI extensions, including ASP and ASP.NET. The IsapiModule has a managed handler that specifies that all files with the .dll extension are to be handled as ISAPI extensions. If you remove this module, ISAPI extensions mapped as handlers or explicitly called as ISAPI extensions won't work anymore.

IIS uses ISAPI filters to provide additional functionality. If you selected ASP.NET during initial configuration, an ASP.NET filter is configured to provide classic functionality through aspnet_filter.dll, an ISAPI filter. For classic ASP.NET functionality, each version of ASP.NET installed on a Web server must have a filter definition that identifies the version and path to the related filter. After you install new versions of ASP.NET, you can add definitions for the related filter.

ISAPI and CGI restrictions control the allowed ISAPI and CGI functionality on a server. When you want to use an ISAPI or CGI application, you must specifically allow the related DLL or EXE to run.

Understanding and Using ASP.NET Applications

When you are working with ASP.NET, it is important to consider the managed pipeline mode you will use. IIS 7.0 supports two modes for processing requests to ASP.NET applications:

• Classic

• Integrated

Classic pipeline mode, depicted in Figure 3-2, is the standard processing mode used with IIS 6.0. If a managed Web application runs in an application pool with classic mode, IIS processes the requests in an application pool by using separate processing pipelines for IIS and ISAPI. This means that requests for ASP.NET applications are processed in multiple stages like this:

Figure 3-2. Here is a conceptual view of classic ASP.NET processing.

[View full size image]

Integrated pipeline mode, depicted in Figure 3-3, is a dynamic processing mode that can be used with IIS 7.0. If a managed Web application runs in an application pool with integrated mode, IIS processes the requests in an application pool by using an integrated processing pipeline for IIS and ASP.NET. This means that requests for ASP.NET applications are processed directly like this:

Figure 3-3. A conceptual view of integrated ASP.NET processing.

[View full size image]

From an administrator perspective, applications running in classic pipeline mode can appear to be less responsive than their integrated counterparts. From an application developer perspective, classic pipeline mode has two key limitations. First, services provided by ASP.NET modules and applications are not available to non-ASP.NET requests. Second, ASP.NET modules are unable to affect certain parts of IIS request processing that occurred before and after the ASP.NET execution path.

With an integrated pipeline, all native IIS modules and managed modules can process incoming requests at any stage. This enables services provided by managed modules to be used for requests to pages created using static content, ASP.NET, PHP, and more. Direct integration makes it possible for developers to write custom authentication modules, to create modules that modify request headers before other components process the request, and more.

When working with the integrated pipeline mode, it is important to keep in mind that in this mode ASP.NET does not rely on the ISAPI or ISAPI Extension modules. Because of this, the running of an integrated ASP.NET application is not affected by the ISAPI CGI restriction list. The ISAPI CGI restriction list applies only to ISAPI and CGI applications (which includes ASP.NET classic applications). For integrated mode to work properly, you must specify handler mappings for all custom file types.

Further, many applications written for classic pipeline mode will need to be migrated to run properly in integrated pipeline mode. The good news is that the Configuration Validation module, included as a part of the server core, can automatically detect an application that requires migration and return an error message stating that the application must be migrated. You can migrate applications by using Appcmd.exe (general-purpose IIS command-line administration tool). Any migration error reported by IIS typically contains the necessary command for migrating the application. To use this command to migrate an application automatically, right-click the command-prompt icon and choose Run As Administrator. You then can migrate an application manually by running the following command at the elevated command prompt:

appcmd migrate config AppPath

where AppPath is the virtual path of the application. The virtual path contains the name of the associated Web site and application. For example, if an application named SalesApp was configured on the Default Web Site and needed to be migrated, you could do this by running the following command:

appcmd migrate config "Default Web Site/SalesApp"

When AppCmd finishes migrating the application, the application will run in both classic and integrated modes.