Essentials for Working with IIS Applications | Microsoft IIS 6.0Administrator's Consultant

The Internet Server Application Programming Interface (ISAPI) provides the core functionality for the application architecture. As depicted in Figure 5-1, ISAPI acts as a layer over IIS that can be extended using ISAPI applications, Active Server Pages (ASP), ASP.NET, and third-party extensions. The following sections provide an overview of ISAPI applications, ASP, and ASP.NET. Because third- party IIS extensions behave much like ISAPI applications, they aren’t examined separately.

click to expand
Figure 5-1: ISAPI acts as a layer over IIS.

Understanding ISAPI Applications

ISAPI applications fall into two categories:

ISAPI filters
ISAPI extensions

You use both filters and extensions to modify the behavior of IIS. ISAPI filters are dynamic-link libraries (DLLs), or executables, that are loaded into memory when the World Wide Web Publishing Service is started and remain in memory until the IIS server is shut down. ISAPI filters are triggered when a Web server event occurs on the IIS server. For example, you could create a filter that responds to Read events by logging the client’s browser type in a database.

You can apply ISAPI filters globally or locally. Global filters affect all IIS Web sites running on a server and are loaded into memory when the World Wide Web Publishing Service is started. Anytime you add new global filters or modify existing global filters, you must stop and then restart the World Wide Web Publishing Service. Local filters are called site filters. Site filters affect a single IIS Web site and can be dynamically loaded into memory when a request that uses such a filter is made to the site.

When several filters are configured to respond to the same events, they’re executed sequentially. Administrators can control the sequence by assigning priority levels to filters. Filters with higher priority are executed before filters with lower priority. Filters with the same priority are executed at the global level, as specified in the master World Wide Web properties, and then at the site level, as specified in the Web site properties. Filters with the same priority at the same level within IIS are executed according to the order in which they were loaded into memory. If you discover a conflict, you can change the filter load order as necessary.

ISAPI filters aren’t ideal choices when you need to perform long-running operations, such as database queries, or when you want to process the entire body of requests. In these instances ISAPI extensions work better.

Like ISAPI filters, ISAPI extensions are defined as DLLs or executables. Unlike global filters, which are loaded with the World Wide Web Publishing Service, extensions are loaded on demand and are executed in response to client requests. Normally, ISAPI extensions are used to process the data received in requests for specific types of files. For example, when a client makes a request for a file using the .asp extension, IIS uses the Asp.dll ISAPI extension to process the contents of ASP and return the results to the client for display.

When you install IIS, default ISAPI extensions are configured for use on the Web server. ISAPI extensions are configured to respond to specific types of Hypertext Transfer Protocol (HTTP) requests or all HTTP requests for files with a specific file extension. The key types of HTTP requests are summarized in Table 5-1.

Table 5-1: HTTP Request Types Used with ISAPI Extensions
Request Type	Description
DELETE	A request to delete a resource. This request normally isn’t allowed unless the user has specific privileges on the Web site.
GET	A request to retrieve a resource. The standard request for retrieving files.
HEAD	A request for an HTTP header. The return request doesn’t contain a message body.
OPTIONS	A request for information about communications options.
POST	A request to submit data as a new subordinate of a resource. Typically used for posting data from fill-out forms.
PUT	A request to store the enclosed data with the resource identifier specified. Typically used when uploading files through HTTP.
TRACE	A request to trace the client’s submission (for testing or debugging).

Because ISAPI extensions are loaded on demand, you can add extensions at any time without having to restart IIS. However, if you modify an ISAPI extension that’s already loaded into memory, you must stop and then restart the World Wide Web Publishing Service to apply the new configuration settings. As with ISAPI filters, ISAPI extensions have global and local context. If you set an ISAPI extension in the master World Wide Web properties, the extension is available to all Web sites on the server. On the other hand, if you set an ISAPI extension in a site’s properties, the extension is available only on that site.

ISAPI extensions don’t have priorities and you shouldn’t configure multiple ISAPI extensions to handle the same type of content. In addition, ISAPI extensions always run in a single server process. This process can be the same server process as the one used by IIS, a pooled process shared by multiple applications, or an isolated process.

Understanding ASP Applications

ASP is a server-side scripting environment used to create dynamic Web applications. An ASP application is a collection of resource files and components that are grouped logically. Logically grouping files and components as an application allows IIS to share data within the application and to run the application as a shared, pooled, or isolated process. You can have multiple applications per Web site, and you can configure each application differently.

IIS resource files include ASP pages, HTML pages, GIF images, JPEG images, and other types of Web documents. An ASP page is a file that ends with the .asp extension that includes HTML, a combination of HTML and scripting, or only scripting. Scripts within ASP pages can be intended for processing by a client browser or the server itself. Scripts designed to be processed on the server are called server-side scripts and can be written using Microsoft Visual Basic Scripting Edition (VBScript), Microsoft JScript, or any other scripting language available on the server.

ASP provides an object-based scripting environment. Server-side scripts use the built-in objects to perform common tasks, such as tracking session state, managing errors, and reading HTTP requests sent by clients. A list of built-in objects is provided in Table 5-2.

Table 5-2: Built-In ASP Objects
Built-In Object	Description
Application	Used to share information among all users of an ASP application.
ASPError	Tracks information about error conditions that have occurred in scripts on ASP pages.
ObjectContext	Maintains information on application component instances and provides access to the built-in ASP objects. Also provides methods and events used to commit or abort transactions.
Request	Obtains the values sent in the HTTP request by the client browser.
Response	Sends the HTTP response to the client browser.
ScriptingContext	Provides access to built-in objects. Supported for backward compatibility only. Use ObjectContext instead.
Server	Used to perform server-related tasks, such as executing files and transferring state information to another ASP page, and to instantiate server components.
Session	Stores information about a specific user session (provided the user’s browser supports cookies and cookies are enabled).

ASP scripts can also use IIS components. IIS components are executable programs that use the Component Object Model (COM) and Component Services to communicate with IIS. Prebuilt components are available in the standard IIS 6 installation and as part of the IIS 6 Resource Kit. Table 5-3 summarizes the available components. Components marked with an asterisk can be found in the %SystemRoot%\System32\Inetsrv directory on the IIS server. The other components must be obtained from the resource kit. If you remove the components from the %SystemRoot%\System32\Inetsrv directory, they’ll no longer be available to your ASP applications.

Table 5-3: Prebuilt Components for ASP Applications
Prebuilt Component	Description
Ad Rotator (Adrot.dll)*	Rotates banner ads displayed on a Web page according to a specified schedule.
Browser Capabilities (Browsercap.dll)*	Determines the capabilities, type, and version of each browser that accesses your Web site.
Content Linking (Nextlink.dll)*	Creates tables of contents for Web pages and provides navigational links to previous and subsequent pages.
Content Rotator (Controt.dll)*	Rotates HTML content on a Web page according to a specified schedule.
Counters (Counters.dll)*	Creates a counter that tracks page hits for an entire Web site and access to individual pages.
Logging Utility (Logscrpt.dll)	Allows applications to read the HTTP activity log files generated by IIS.
MyInfo (Myinfo.dll)	Tracks personal information pertaining to the site or its creator.
Page Counter (Pagecnt.dll)	Counts and displays the number of times a Web page has been accessed.
Status (Status.dll)	Returns server status information when running Personal Web Server for Macintosh.
Tools (Tools.dll)	Provides utility functions that check file existence, match site ownership, look for plug-ins (Macintosh only), process HTML form data, and generate random integers.

Understanding ASP.NET Applications

ASP.NET moves away from the reliance on ISAPI and ASP to provide a reliable framework for Web applications that takes advantage of the Microsoft .NET Framework. ASP.NET is, in fact, a set of .NET technologies for creating Web applications. With ASP.NET, developers can write the executable parts of their pages using any .NET-compliant language, including Microsoft Visual C# .NET, Visual Basic .NET, and JScript .NET.

Unlike ASP, ASP.NET has components that are precompiled prior to runtime. These precompiled components are called assemblies. Compiled assemblies not only load and run faster than ASP pages, but also are more secure. Requests for ASP.NET assemblies are handled quite differently from other requests. The basic request handling process looks like this:

Request IIS aspnet_isapi.dll HttpApplication HttpHandler HttpModule

A global ISAPI filter provides the hooks into ASP.NET. This filter, aspnet_filter.dll, is loaded into memory automatically when run on an IIS 6 Web server that’s configured to use ASP.NET. IIS maps ASP.NET file extensions to this ISAPI filter. This filter’s job is to forward requests to the correct worker process.

Note

As you might recall from the discussion in Chapter 2, ASP.NET uses its own processing model when IIS runs in IIS 5 isolation mode. This processing model is similar to worker process isolation mode and has similar capabilities. On the other hand, when running a server in IIS 6 worker process mode, ASP.NET and IIS are directly integrated. Here, ASP.NET uses the worker process model architecture of IIS 6, and ASP.NET applications can take advantage of IIS 6 features.

The ASP.NET worker process wraps the request into an instance of the HttpContext class, which is used to represent the request as an object that the current instance of the ASP.NET application can view and manipulate. The HttpContext object is then passed off to an instance of the HttpApplication class, which maintains information on application scope, data, and events. A specific HttpHandler is then chosen based on the original request’s file extension, and one or more HttpModule objects processes the request. HttpModule has many event classes, such as BeginRequest, AuthenticateRequest, and AuthorizeRequest, which are used to process the request.

As shown in Figure 5-2, you configure and manage ASP.NET assemblies using the .NET Configuration snap-in for the Microsoft Management Console (MMC). The .NET configuration has five key components:

Assembly Cache Contains sets of assemblies that are available to all .NET applications running on the server. The default installation includes a large number of predefined assemblies, which provide the core functions that can be accessed from .NET applications.
Configured Assemblies Contains sets of assemblies that you’ve configured with additional policies. Assemblies can have policies for version binding or assembly codebases, or both. Binding policies are useful when you need to redirect requests for particular versions of an assembly to new versions of the assembly. Codebase policies allow you to specify the codebase location for various assembly versions.
Remoting Services Configures the communications channels that applications use. Each channel, such as HTTP client or Transmission Control Protocol (TCP) client, can have different properties to configure.
Runtime Security Policy Configures assemblies permissions to access protected resources. You can adjust the level of trust for individual assemblies or all assemblies according to security zone (My Computer, Local Intranet, Internet, Trusted Sites, Untrusted Sites). You can also view permissions granted to specific assemblies.
Applications Allows you to view and configure .NET applications. You can check assembly dependencies, configured assemblies, and remoting services configurations.

Figure 5-2: Use .NET Configuration to view and manage ASP.NET assemblies.

Defining Custom Applications

You use the IIS snap-in to configure custom applications, .NET Configuration to manage .NET assemblies, and the Component Services snap-in to manage COM components. As part of the standard installation, Web sites have a predefined application that allows you to run custom programs without making changes to the environment. You could, for example, copy your ASP files to a site’s base directory and run them without creating a separate application. Here, the ASP application you’ve defined runs as a default application within the context of the default application pool.

Real World

Novice administrators who don’t understand its purpose often accidentally or purposefully remove the default application pool. If this happens, application behavior might change. For example, you suddenly might be unable to share session states between ASP pages. The reason for this is that ASP pages and other types of files that were using the default application pool no longer have an application context, and all associated application pool settings are no longer available.

To be clear, the default application pool allows you to run IIS applications regardless of where they might be located within the site’s directory structure, as long as the directories in which those files are located have the appropriate execute permissions (either Scripts Only or Scripts And Executables). If you want to delete the default application pool, you should create specific application pool contexts for each application that you want to run.

To get better control over applications, you should configure separate contexts for key applications. Application contexts are defined using basic and advanced application settings. Basic application settings include the following:

Application Name A descriptive name for the application.
Starting Point Sets the base directory for the application. All files in all subdirectories of the base directory are considered to be part of the application.
Execute Permissions Sets the level of program execution that’s allowed.
Application Protection Determines how the application runs and which application resources are shared with IIS and other applications (only used with IIS 5 isolation mode).
Application Pool Determines which application pool is used with the application. You can configure multiple application pools, and each can have a different worker process configuration (only used with IIS 6 worker process mode).

Advanced application settings include:

Application Mappings Sets application caching and maps file extensions to DLLs for execution
Application Options Sets configuration options that control how the application runs, including time-outs, buffering, and the default scripting language
Application Debugging Enables or disables debugging and script error messages

Application settings create application contexts within which your application runs. Without an application context, your customized pages run as separate files and are unable to take advantage of key IIS features. Application contexts are defined at the directory level. All files in all subdirectories of the application’s base directory are considered to be part of the application. Because of this, the best way to create applications is to follow these steps:

In Windows Explorer, create a folder that will act as the application’s starting point and then set appropriate access Windows permissions on the folder.
Use the IIS snap-in to create a virtual directory that maps to the directory.
Configure application settings for the directory as defined in the “Creating Applications” section of this chapter.

Using and Running Applications

Each application has a starting point. The starting point sets the logical namespace for the application. That is, the starting point determines the files and folders that are included in the application. Every file and folder in the starting point is considered part of the application.

You can define application starting points for the following:

An entire site
A directory
A virtual directory

When you define a sitewide application, all files in all the Web site’s subdirectories are considered to be a part of the application. When you define an application for a standard or virtual directory, all files in all subdirectories in this directory are considered part of the application.

As stated earlier, the application starting point sets the namespace for an application. A namespace is a way of associating an area of memory with an easily recognized name that associates a group of files and components. The memory area used by an application determines its protection setting.

Application Protection Settings in IIS 5 Isolation Mode

In IIS 5 isolation mode, there are three application protection settings:

Low (IIS Process) Low protection allows applications to run in process and share resources with IIS. Low protection provides the best performance but makes it possible for a stray application to crash IIS.
Medium (Pooled) Medium protection allows applications to run as a pooled process, which means that all applications with this priority share the same IIS process instance but don’t run in process with normal IIS resources. If a single application fails, it will affect all other applications running at medium protection—but it won’t affect IIS itself.
High (Isolated) High protection allows applications to run completely out of process (or isolated), which means that the application doesn’t share processes with other applications and the failure of other applications doesn’t affect this high-priority application.

If you use medium or high protection settings, you allow IIS to isolate the application to a specific process. Process isolation protects the server’s World Wide Web Publishing Service from application problems that could otherwise cause the Web server to crash or freeze. Process isolation also allows you to configure scheduled application restarts and automatic termination of application processes in case of a fatal error.

Application protection settings affect memory access. Applications that share the same process as IIS share the same memory area and are able to call each other with little overhead. Applications that share a pooled process or are isolated must use a process called marshaling to make requests across process boundaries. Marshalling is required whenever an application needs to interact with IIS or other applications. Because marshaled calls are slower than calls within a single process, pooled and isolated applications don’t perform as well as applications sharing the IIS process.

Out-of-process applications and components, including ISAPI extensions, aren’t able to access metabase properties by default. This restriction is designed to prevent unauthorized changes to the metabase. If you want to allow out-of-process applications to access the metabase, you should change the identity for out-of- process applications to a specific user account and give that account access to the metabase.

Tip

You use the Component Services snap-in to manage authentication for application components. In the Component Services snap- in, expand Component Services, then Computers, then My Computer, and then COM+ Applications. Right-click IIS Out-Of-Process Pooled Applications, select Properties, and then select the Identity tab. The user context to which you assign the application must have file permissions to access the metabase. To check file permissions, right-click the metabase file (%SystemRoot%\System32\Inetsrv\MetaBase.xml) in Windows Explorer, select Properties, and then select the Security tab.

In IIS 5 isolation mode, application protection and caching settings change the way memory is used on your IIS server. The operating system incurs additional overhead every time a new application is started and every time new programs are loaded into memory. The amount of overhead depends on the application configuration settings. To obtain a basic understanding of the overhead for applications, consider the following scenario:

An IIS server is configured with three Web sites: a corporate Web site, a service Web site, and an administration Web site. The server is also running a Simple Mail Transfer Protocol (SMTP) server. In the baseline configuration, the server runs the following IIS processes:

Inetinfo.exe This process is used to manage the service hosts and ISAPI applications that run within the IIS process context.
Svchost.exe These three processes control Web resources, SMTP resources, and the baseline installation.
Dllhost.exe This process is used to manage IIS processes (and any in- process applications that might be defined). No pooled or out-of-process applications are defined initially.

As Table 5-4 shows, these baseline processes use 27,848 KB of memory on the server. To determine how application processing affects the server, I defined additional applications:

Pooled Application 1 An application running with medium application protection
Pooled Application 2 An application running with medium application protection
Isolated Application 1 An application running with high application protection

Isolated Application 2 An application running with high application protection

Table 5-4: Application Overhead Baselines for Sample Server
Process	Baseline IIS	Pooled Application 1	Pooled Application 2	Isolated Application 1	Isolated Application 2
Inetinfo.exe	7568	8360	8388	8440	8472
Dllhost.exe	4968	4968	4968	4960	4960
Dllhost.exe	NA	5436	5492	5080	5080
Dllhost.exe	NA	NA	NA	5460	5460
Dllhost.exe	NA	NA	NA	NA	5248
Svchost.exe	3060	3080	3080	3084	3100
Svchost.exe	9908	9920	9920	9920	9920
Svchost.exe	2344	2344	2344	2344	2344
Total Memory Usage (KB)	27,848	34,108	34,192	39,288	44,584

Although the process of defining applications doesn’t really affect the baseline configuration, running the applications does affect memory usage. When I use Pooled Application 1, a new Dllhost.exe process is started and the base memory usage changes to 34,108 KB. Because the additional Dllhost.exe process is used to manage all pooled applications, starting the second pooled application (Pooled Application 2) doesn’t spawn any new processes and the additional memory usage is minimal. On the other hand, each time I start a new isolated application, a new Dllhost.exe process is started, and an incremental amount of memory is used. Running Isolated Application 1 causes a third Dllhost.exe process to start, and the baseline memory usage goes to 39,288 KB. Running Isolated Application 2 causes a fourth Dllhost.exe process to start, and the baseline memory usage goes to 44,584 KB.

As you can see from the example, each new Dllhost.exe host process used about 5000 KB of additional memory, and, in the end, IIS used about 45,000 KB of memory on the server. Although this isn’t a lot of memory, a server with more complex applications could use considerably more memory, especially as additional ISAPI extensions and Common Gateway Interface (CGI) programs are loaded into memory. Servers also cache Web documents, and a portion of memory is always reserved for this file cache.

Application Protection Settings in IIS 6 Worker Process Isolation Mode

In IIS 6 worker process isolation mode, all applications run completely out of process with IIS. There are no longer any in-process applications. Because applications don’t share processes or files with other applications, the failure of one application shouldn’t affect other applications.

Request processing in this mode is a bit different from what you might be used to. First of all, IIS 6 uses a kernel mode HTTP listener (Http.sys) to watch for incoming requests. As requests come in, the listener queues requests in the appropriate application pool request queue. Although application pools can have multiple applications associated with them, each application pool has one and only one request queue.

The queue is managed in first in, first out (FIFO) fashion with dedicated worker processes monitoring the queue for incoming requests. Each application can have one or more dedicated worker processes. Worker processes are said to be dedicated because no other application pool can use another application pool’s worker process. If a process dedicated to the application pool for which the request has been made is available, the worker process retrieves the request from the queue and processes it. When it’s finished, the process returns to an idle state and waits for the next request to come into the queue.

Unlike IIS 5 isolation mode, where the operating system incurs additional overhead based on whether applications are in process or out of process, applications in IIS 6 worker process mode always operate out of process. This means memory is allocated every time a new application is started and every time new programs are loaded into memory. The good news, however, is that IIS 6 is much smarter in the way memory is allocated.

Memory is allocated on demand (rather than automatically at startup) when the first request for a resource serviced by the application arrives in the request queue. Further, in the IIS 6 mode, idle processes can time out, thereby returning the resources they use. Errant (or orphan) processes can also be automatically recycled to free resources and recover resources that might have been lost due to a memory leak or hung process.

The new model is best understood when you compare the IIS 5 model to the IIS 6 model. If you go back to the example described in the previous section and refer to Table 5-4, you see that applications configured on a Web server can use up memory quickly, especially when you consider that I’ve created a single site, single server example. Now imagine a more typical scenario where a single Web server is hosting multiple sites. IIS 5 pre-allocates memory at startup for each site, and then, when applications are started, additional memory is allocated. The pages served by those applications in turn could have static and dynamic components that are cached. On a busy server with lots of dynamic sites, several gigabytes of memory can get used up quickly this way.

In contrast, on the same server running IIS 6, where memory is allocated on demand to processes and application components and then returned when idle or otherwise recycled, the resource usage is very different. The same server that was previously bogged down can handle many more sites and applications.