Managing Custom IIS Applications

You configure and manage custom IIS applications through the Web Site Properties dialog box. As part of the standard installation, all Web sites created in IIS have a default application that’s set as a sitewide application, meaning its starting point is the base directory for the Web site. The default application allows you to run custom applications that use the preconfigured application settings. You don’t need to make any changes to the environment. You can, however, achieve better control by defining applications with smaller scope, and the sections that follow tell you how to do this.

Creating Applications

IIS applications are collections of resource files and components that are grouped together to take advantage of key IIS features. In IIS 5 isolation mode, those features include file buffering, session state tracking, and component caching. In IIS 6 mode, those features include worker process recycling, health monitoring, and rapid fail protection.

You can create an application by completing the following steps:

1. In the IIS snap-in, right-click the site, directory, or virtual directory that you want to use as the starting point for the application and then select Properties. Select the Home Directory, Directory, or Virtual Directory tab as appropriate. This displays the dialog box shown in Figure 5-3.

   
   Figure 5-3: Use the Properties dialog box to configure custom applications.

2. You use the fields in the Application Settings frame to configure the application. If the Application Name and Application Pool fields appear dimmed, it means that the directory is already within the context of another application. This is all right; you can still create your application. However, keep in mind that by doing so, you remove the directory and all its subdirectories from the current application context.

3. Click Create to start the application definition process. If an application was created by default, you might need to click Remove first.

4. The Application Name field sets a descriptive name for the application. By default, this field is set to the directory name. You can change this value by typing a new name.

5. Use the Execute Permissions selection drop-down list to set the level of program execution that’s allowed for an application. Three execute permissions levels are defined:

   • None Only static files, such as HTML or GIF files, can be accessed.

   • Scripts Only scripts, such as ASP scripts, can be run.

   • Scripts And Executables All file types can be accessed and executed.

6. If running in IIS 5 isolation mode, use the Application Protection selection list to specify the memory area used by the application as one of the following:

   • Low (IIS Process) Low protection allows applications to run in process and share resources with IIS. All applications with this priority share the IIS process instance.

   • Medium (Pooled) Medium protection allows applications to run as a pooled process. All applications with this priority share the same IIS process instance but don’t run in process with normal IIS resources.

   • High (Isolated) High protection allows applications to run completely out of process. Isolated applications don’t share processes with other applications, and the failure of other applications doesn’t affect this high-priority application.

7. If running in IIS 6 worker process mode, select the application pool to use. Although you can use the default application pool (DefaultAppPool), it’s better to create pools for specific types of applications and sites as discussed in Chapter 6.

8. Create the application by clicking Apply. You then have the option to click Configuration to configure advanced settings. Advanced settings are discussed in the sections that follow.

Configuring Application Mappings and Caching

Application mappings are used to specify the ISAPI extensions and CGI programs that are available to applications. Application mappings for Web sites are inherited from the WWW Service master properties at the time the site is created. Application mappings for individual directories are inherited from the site properties at the time the directory is created and made available to IIS. Each application mapping has three components:

• Extension The file extension that’s associated with the ISAPI extension or CGI program. File extensions don’t have to have file type associations at the operating system level and can be more than three characters.

• Executable Path The file path to the ISAPI extension or CGI program. IIS uses the executable path to determine which ISAPI extension or CGI program should be loaded. The associated DLL or executable must be in a directory that’s accessible to IIS. Typically, this means placing the DLL or executable in the %SystemRoot%\System32 or %SystemRoot%\ System32\Inetsrv directory. If you’re using extensions included with the .NET Framework, the DDL or executable would be located within the %SystemRoot%\Microsoft.NET\ Framework\ directory structure.

• Verbs The HTTP request types that are used with the ISAPI extension or CGI program. For a detailed list of HTTP request types, refer to Table 5-1.

ISAPI extensions and CGI programs with mappings are loaded dynamically into memory when IIS receives a request for a file with the designated extension, and they’re unloaded when IIS is finished processing the request. You can change this behavior by enabling application caching. With caching enabled, IIS doesn’t unload the associated DLL or executable but instead maintains it in memory.

You control ISAPI extension caching at the site level of the Web site you are working with. This setting is inherited by all applications configured on the site and cannot be set differently for individual applications within the site. To view or manage ISAPI extension caching, follow these steps:

1. In the IIS snap-in, right-click the site that you want to work with and then select Properties.

2. On the Home Directory tab, click Configuration.

3. Enable application caching by selecting Cache ISAPI Extensions. Clear this check box to disable caching.

4. Click OK twice.

   Note

   In most instances, you’ll want IIS to use extension caching. The exception is when you are doing debugging or troubleshooting and want to force IIS to reload components each time they’re used.

Unlike ISAPI extension caching, you have granular control over application mappings and can set mappings for individual directories differently from the mappings used for the site as a whole. You control application mappings through the Application Configuration property sheet shown in Figure 5-4. To access this property sheet, follow these steps:

1. In the IIS snap-in, right-click the site, directory, or virtual directory that’s used as the starting point for the application and then select Properties.

2. Select the Home Directory, Directory, or Virtual Directory tab as appropriate and then click Configuration.

3. The Application Extensions frame shows the current mappings for ISAPI extensions and CGI programs. As shown in Figure 5-4, each application mapping has an associated file extension, executable path, and verb list.

   
   Figure 5-4: Use the Application Configuration property sheet to control which components are available to IIS applications and how those components are managed in memory.

Once the Application Configuration property sheet is displayed, you can manage existing component mappings or create new component mappings. The techniques for doing this are examined in the following sections.

Adding Application Mappings

To add application mappings, follow these steps:

1. Access the Application Configuration property sheet for the application and then click Add. This displays the Add/Edit Application Extension Mapping dialog box, as shown in Figure 5-5.

   
   Figure 5-5: Add new application mappings using the Add/Edit Application Extension Mapping dialog box.

2. In the Executable field, type the file path to the ISAPI extension or CGI program that you want to use. The file path should end in .exe or .dll, such as C:\Windows\System32\Inetsrv\Asp.dll. If you don’t know the file path, click Browse to display the Open dialog box, which you can use to find the executable.

   Note

   The DLL or executable must be located on a local hard disk. In most cases, DLL or executables should be placed in the %SystemRoot%\System32 or %SystemRoot%\System32\Inetsrv directory.

3. In the Extension field, type the file name extension that should be associated with the ISAPI extension or CGI program. Be sure to include the period (.) with the extension designator, such as .html.

   Tip

   If you want the ISAPI extension or CGI program to handle requests for all file types, place an asterisk (*) in the Extension field. From then on, requests for files within the application scope are sent to the component you’ve specified regardless of the file extension. Keep in mind that file requests also must match the parameters set for the verb list.

4. Use the options in the Verbs frame to set the verb list for the application mapping. Select All Verbs to pass all requests with the defined extension to the application or select Limit To and then enter request types in a comma- separated list.

   Note

   The verb list controls the types of requests that are passed to an application. For example, you could configure one mapping to handle GET, HEAD, and POST requests for .htm files and another mapping to handle PUT, TRACE, and DELETE requests for .htm files.

5. Applications can run in directories with Scripts Only or Scripts And Executable permissions. If you want the ISAPI extension or CGI program to run in directories designated as Scripts Only, select the Script Engine check box. Otherwise, clear this check box and the component will run only in directories designated with Scripts And Executable permissions.

6. Select Verify That File Exists to have IIS check the existence of a requested file and to ensure that the user making the request has appropriate access permissions before running the associated ISAPI extension or CGI program. If the file doesn’t exist or if the user doesn’t have access permissions, a warning message is returned to the browser and the component isn’t executed.

   Note

   Verify That File Exists is useful when you use scripts mapped to executables that don’t send a CGI response if a script is inaccessible. One such example is Perl, which doesn’t return a CGI response in this instance. Using this option can cause a performance hit on a busy server. The reason for this is that the file is opened twice—once by IIS and once by the associated component.

7. Click OK three times to return to the IIS snap-in.

Editing Application Mappings

You can edit existing application mappings by completing the following steps:

1. Access the Application Configuration property sheet for the application, select the desired mapping, and then click Edit. This displays the Add/Edit Application Extension Mapping dialog box previously shown in Figure 5-5.

2. Make the necessary adjustments to the mapping and then click OK three times to return to the IIS snap-in.

3. The new settings are used the next time the associated DLL or executable is loaded into memory. If ISAPI caching is enabled, you must stop and then restart the Web site to enforce the changes.

Removing Application Mappings

To remove application mappings, follow these steps:

1. Access the Application Configuration property sheet for the application, select the desired mapping, and then click Remove.

2. When prompted to confirm the action, click Yes, then click OK twice to return to the IIS snap-in.

3. The new settings are used the next time the associated DLL or executable is loaded into memory. If ISAPI caching is enabled, you must stop and then restart the Web site to enforce the changes.

Managing Session State

Session state plays a significant role in IIS performance and resource usage. When session state is enabled, IIS creates a session for each user who accesses an ASP application. Session information is used to track the user within the application and to pass user information from one page to another. For example, your company might want to track individual user preferences within an application, and you can use sessions to do this.

The way sessions work is fairly straightforward. The first time a user requests an ASP page with a specified application, IIS generates one of the following:

• A Session object containing all values set for the user session, including an identifier for the code page used to display the dynamic content, a location identifier, a session ID, and a time-out value.

• A Session.Contents collection, which contains all the items that the application has set in the session (except objects created in the application’s Global.asa file).

• A Session.StaticObjects collection, which contains the static objects defined in the application’s Global.asa file.

The Session object and its associated properties are stored in memory on the server. The user’s session ID is passed to the user’s browser as a cookie. As long as the browser accepts cookies, the session ID is passed back to the server on subsequent requests. This is true even if the user requests a page in a different application. The same ID is used in order to reduce the number of cookies sent to the browser. Keep in mind that if the browser doesn’t accept cookies, the session ID can’t be maintained and IIS can’t track the user session using this technique. In this case you could track the session state on the server.

Session state is enabled by default for all IIS applications. By default, sessions time out in 20 minutes. This means that if a user doesn’t request or refresh a page within 20 minutes, the session ends and IIS removes the related Session object from memory. You can change the default time-out value using the Session Timeout property on the Options tab of the Application Configuration property sheet.

Real World

Worker process recycling can affect session management. If a worker process is recycled or otherwise cleared out of memory, the session state could be lost. If this happens, you won’t be able to recover the session data.

As you might imagine, tracking sessions can use valuable system resources. You can reduce resource usage by reducing the time-out interval or disabling session tracking altogether. Reducing the time-out interval allows sessions to expire more quickly than usual. Disabling session tracking tells IIS that sessions shouldn’t be automatically created. You can still start sessions manually within the application. Simply place the <%@ENABLESESSIONSTATE = True%> directive in individual ASP pages.

Each application configured on your server has its own session state settings. You manage the session state for an application by completing the following steps:

1. In the IIS snap-in, right-click the site, directory, or virtual directory that’s used as the starting point for the application and then select Properties.

2. Select the Home Directory, Directory, or Virtual Directory tab as appropriate and then click Configuration.

3. In the Options tab, enable automatic session creation by selecting Enable Session State. Clear this check box to disable automatic session creation.

4. If sessions are enabled, type a session time-out value in the Session Timeout field. For a high-usage application in which you expect users to move quickly from page to page, you might want to set a fairly low time-out value, such as 15 minutes. On the other hand, if it’s critical that the user’s session is maintained to complete a transaction, you might want to set a long time-out value, such as 60 minutes.

5. Click OK twice.

   Real World

   These days, most large-scale, commercial Web sites are managed using multiple servers. In this situation you typically have a load balancer that distributes requests for the site Uniform Resource Locator (URL) to whichever server is available. To use ASP session management on a load-balanced site, you must ensure that all requests from a particular user are directed to the same Web server. The technique you use depends on your load balancer.

Controlling Application Buffering

Buffering is another option that affects server performance and resource usage. When buffering is enabled, IIS completely processes pages before sending content to the client browser. When buffering is disabled, IIS returns output to the client browser as the page is processed. The advantage to buffering is that it allows you to respond dynamically to events that occur while processing the page. You can take one of the following actions:

• Abort sending a page or transfer the user to a different page

• Clear the buffer and send different content to the user

• Change HTTP header information from anywhere in your ASP script

A disadvantage of buffering is that users have to wait for the entire script to be processed before content is delivered to their browser. If a script is long or complex, the user might have to wait for a long time before seeing the page. To counter potential delays associated with buffering, developers often insert Flush commands at key positions within the script. If your development team does this, they should be aware that this causes additional connection requests between the client and server, which might also cause performance problems.

As with session tracking, buffering is enabled by default for all applications. You manage buffering by completing the following steps:

1. In the IIS snap-in, right-click the site, directory, or virtual directory that’s used as the starting point for the application and then select Properties.

2. Select the Home Directory, Directory, or Virtual Directory tab as appropriate and then click Configuration.

3. In the Options tab, enable buffering by selecting Enable Buffering. Clear this check box to disable buffering.

   Tip

   If you disable buffering for an application, you can still turn on buffering for individual ASP pages. To do this, use the Response.Buffer = True statement.

4. Click OK twice to return to the IIS snap-in.

Setting Parent Paths, Default ASP Language, and ASP Script Time-Out

Additional options that you can set for applications pertain to parent paths, default ASP language, and ASP script time-out. Enable Parent Paths allows ASP pages to use relative paths to access the current directory’s parent directory. For example, a script could reference ../Build.htm, where “..” is a reference to the current directory’s parent directory. Parent paths are enabled by default.

Default ASP Language sets the default scripting language for ASP pages. Two scripting engines are installed with a standard IIS installation. These scripting engines are for VBScript and JScript. You can reference these scripting engines using the values VBScript and JScript, respectively. The default scripting language in a standard IIS installation is VBScript, but you can change the default value at any time. Scripts can override the default language using the <%@LANGUAGE%> directive.

ASP Script Timeout sets the length of time that IIS allows a script to run. If a script doesn’t complete within the time-out interval, IIS stops the script and writes an error to the application event log. The default time-out value is 90 seconds, but you can set a new default value at any time. In an ASP page, you can override the default value using the Server.ScriptTimeout method.

To set these application options, follow these steps:

1. In the IIS snap-in, right-click the site, directory, or virtual directory that’s used as the starting point for the application and then select Properties.

2. Select the Home Directory, Directory, or Virtual Directory tab as appropriate and then click Configuration. Select the Options tab.

3. Select Enable Parent Paths to allow scripts to use relative paths to reference the parent directory. Clear this check box to disable parent paths.

4. The default scripting language is VBScript. To change the default scripting language, type the scripting language name in the Default ASP Language field.

5. The default ASP script time-out is 90 seconds. To change the default time- out value, type a new time-out interval in the ASP Script Timeout field.

6. Click OK twice to return to the IIS snap-in.

Enabling and Disabling Application Debugging

One of the best ways to troubleshoot an IIS application is to enable debugging. Debugging is handled through server-side and client-side configuration options. Server-side debugging allows IIS to throw errors while processing ASP pages and to display a prompt that allows you to start the Microsoft Script Debugger. You can then use the debugger to examine your ASP pages. Client-side debugging involves sending debugging information to the client browser. You can then use this information to help determine what’s wrong with IIS and the related ASP page.

You can enable server-side and client-side debugging by completing the following steps:

1. In the IIS snap-in, right-click the site, directory, or virtual directory that’s used as the starting point for the application and then select Properties.

2. Select the Home Directory, Directory, or Virtual Directory tab as appropriate and then click Configuration. Select the Debugging tab.

3. To turn on server-side debugging, select Enable ASP Server-Side Script Debugging. To turn off server-side debugging, clear this option.

   Caution

   Server-side debugging of ASP applications is designed for development and staging servers and not necessarily for production servers. If you enable server-side debugging on a production server, you might notice a severe decrease in performance for the affected application. The reason for this is that server-side debugging causes ASP to run in single-threaded mode.

4. To turn on client-side debugging, select Enable ASP Client-Side Script Debugging. To turn off client-side debugging, clear this option.

Configuring Application Error Messages

By default, applications are configured to send to clients detailed error messages that specify the file name, error message, and line number in which an error occurred. This information is great for troubleshooting problems in the code but not necessarily good for users to see when they encounter a problem. For this reason, you might want to create a text message to send instead. The text message can provide readers with an easy-to-understand text message that directs them to a location where they can get help.

You can configure application error messages by completing the following steps:

1. In the IIS snap-in, right-click the site, directory, or virtual directory that’s used as the starting point for the application and then select Properties.

2. Select the Home Directory, Directory, or Virtual Directory tab as appropriate and then click Configuration. Select the Debugging tab.

3. To use detailed error messages, select Send Detailed ASP Error Messages To Client. Otherwise, select Send The Following Text Error Message To Client and type a text message that’s to be displayed if an error occurs.

Unloading IIS 5 Isolated Applications

In IIS 5 mode, isolated applications are stored in a separate memory space and use a separate Dllhost.exe process. If you want to force IIS to remove the application from memory, you can do this by unloading the application. Now the next time a user accesses the application, IIS will reload the application into memory and start a new Dllhost.exe process.

You can unload an isolated application by completing the following steps:

1. In the IIS snap-in, right-click the site, directory, or virtual directory that’s used as the starting point for the application and then select Properties.

2. Select the Home Directory, Directory, or Virtual Directory tab as appropriate.

3. Unload the application by clicking Unload and then click OK.

Deleting IIS Applications

If you find that you no longer need an application, you should remove it to free up the resources that it’s using. To delete an application, follow these steps:

1. In the IIS snap-in, right-click the site, directory, or virtual directory that’s used as the starting point for the application and then select Properties.

2. Select the Home Directory, Directory, or Virtual Directory tab as appropriate.

3. Delete the application by clicking Remove and then click OK.