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, 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:

The incoming HTTP request is received through the IIS core.

The request is processed through ISAPI.

The request is processed through ASP.NET.

The request passes back through ISAPI.

The request passes back through the IIS core where the HTTP response finally is delivered.

Integrated pipeline mode, 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:

The incoming HTTP request is received through the IIS core and ASP.NET.

The appropriate handler executes the request and delivers the HTTP response.

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.

Real World

Although IIS notifies you initially about applications that you need to migrate, IIS will not notify you about migration problems if you subsequently change the application code so that it uses a configuration that is not compatible with integrated mode. In this case, you may find that the application doesn't run or doesn't work as expected, and you'll need to migrate the application manually from a command prompt. If you don't want to see migration error messages, modify the validation element in the application's Web.config file so that its validateIntegratedModeConfiguration attribute is set to false, such as:

*.* Source of Information : Microsoft Press Internet Information Services (IIS) 7.0 Administrator's Pocket Consultant

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.

*.* Source of Information : Microsoft Press Internet Information Services (IIS) 7.0 Administrator's Pocket Consultant

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. 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.

*.* Source of Information : Microsoft Press Internet Information Services (IIS) 7.0 Administrator's Pocket Consultant