Microsoft Windows Server 2003 Deployment Kit—Deploying Microsoft Internet Information Services (IIS) 6.0 [Electronic resources] نسخه متنی

Configuring IIS 6.0 for Optimum Availability

Worker process isolation mode allows you to optimize the availability of applications installed on a Web server. To configure worker process isolation mode for optimum availability of your IIS 6.0 applications and Web sites, you need to determine availability requirements for each application and isolate applications into application pools based on those needs. You can then configure each application pool for recycling, health monitoring, performance, and identity to meet your availability requirements.

Figure 4.3 shows the process for configuring IIS for optimum application availability.

Figure 4.3: Configuring IIS 6.0 for Optimum Availability

Isolating Applications

Because applications in an application pool are isolated from the applications in other application pools by worker process boundaries, if an application fails, it does not affect the availability of applications that are running in other application pools. Deploying applications in application pools is a primary advantage of running IIS 6.0 in worker process isolation mode because you can customize the application pools to achieve the degree of application isolation that you need.

Configuring application isolation involves completing the following steps:

Categorizing applications according to their isolation profiles for initial deployment.

Creating and naming the application pools.

Assigning applications to the appropriate application pools.

If your organization includes network configurations that require more than one server for implementation, such as Web farms, this involves clustering and load balancing. For more information about clustering and load balancing and the specific processes for setting up replication and clustering on IIS, search for "clustering" and "load balancing" in Help and Support Center for Windows Server 2003.

Determining the Application Isolation Needs of Your Server

The applications that you deploy on a server might fit into several categories, based on your assessment of their importance, demand for server resources, or history of instability. Group your applications according to the following categories, or make up your own set of application categories, before assigning your applications to application pools:

Typical . The application is stable and is not subject to extremely high user demand.

High-demand. The application is expected to receive a large number of requests, putting stress on your the resources of your server.

Mission-critical. The application availability is mandatory for business purposes.

Problem. The application must be isolated from other applications and Web sites due to known or anticipated unstable behavior. If you must run test versions of an application on the same server that runs production applications and Web sites, consider it a problem application that must be isolated from all of the other applications on the server.

Unique. The application requires a configuration that is different from other applications that you have categorized as typical. For example, an application might require an identity that has access to more system resources than the default identity.

Creating Application Pools and Assigning Applications to Them

After establishing similar groups for your applications and Web sites, you can assign them to application pools according to the degree of application isolation they require.

To create application pools and assign applications to them when you are deploying a set of Web sites or applications of different types:

Create one application pool for all of the applications that you categorized as typical.

Assign all of the applications categorized as typical to the application pool that you created in Step 1.

Create one application pool for each high-demand, mission-critical, problem, and unique application. Name each application pool after the application that it will contain.

Assign each of your high-demand, mission-critical, problem, and unique applications to the corresponding application pool that you created and named in Step 3.

You can add application pools by using IIS Manager, by using a command-line procedure, or by running Active Directory Service Interfaces (ADSI)- or Windows Management Instrumentation (WMI)-compatible scripts. It is recommended that you use IIS Manager because IIS Manager provides clear, complete, and well-organized visibility to application pools and their properties.

For more information about how to create and name application pools, and how to assign applications to application pools through IIS Manager, see "Isolate Applications in Worker Process Isolation Mode" in "IIS Deployment Procedures" in this book. For information about how to assign applications to application pools by using the command line or scripts, see the AppPoolId property in the "Metabase Property Reference" in IIS 6.0 Help, which is accessible from IIS Manager.

If you create a large number of application pools running many worker processes concurrently, server performance may suffer. The key factor to consider is that large numbers of worker processes with dynamic applications (ASP or ASP.NET applications) may use up available memory.

Unless you have specific reasons for altering the settings for an application pool, deploy your application pools using the default settings. For more information about specific reasons for using non-default settings, see "Recycling Worker Processes," "Tuning Performance," "Managing Application Pool Health," and "Configuring Application Pool Identity" later in this chapter.

Recycling Worker Processes

If an application contains code that causes problems, and you cannot easily rewrite the code, it might be useful to limit the extent of the problems by periodically recycling the worker process that services the application. Worker process recycling is the replacing of the instance of the application in memory. IIS 6.0 can automatically recycle worker processes by restarting the worker process, or worker processes, that are assigned to an application pool. This helps keep problematic applications running smoothly, and minimizes problems such as memory leaks.

You can trigger the recycling of the worker processes assigned to an application pool by using worker process recycling methods that are based on elapsed time, the number of Hypertext Transfer Protocol (HTTP) requests, a set time of day, and two kinds of memory consumption, in addition to recycling on demand. Table 4.1 lists and describes the worker process recycling methods and when to use each.

By setting the values for worker process recycling methods, you can schedule recycling events to manage application problems in a timely manner. Table 4.2 lists recommendations for adjusting the values of worker process recycling methods.

Recycling and Maintaining State

If you have an application pool with applications that depend on state data, then you must decide whether or not to recycle the worker processes that are assigned to that application pool. When you recycle a worker process, the state data for applications that is maintained in process is lost. In this case, do not use recycling.

One alternative to increasing application availability by recycling worker processes is to maintain state data external to the worker process, such as in a database. However, moving data to an external database to allow recycling can affect server performance in the following two ways:

Performance is reduced because of the added data management that is needed to move the data between the application and the database.

Recycling flushes any in-process data caches, so the caches need to be rebuilt.

ASP.NET gives you the option of persisting session state using a session state service or a SQL database. For more information on deploying ASP.NET applications, see "Deploying ASP.NET Applications in IIS 6.0" in this book.

Global Locks and Overlapped Recycling

Using global locks, configuring files for exclusive read, and other methods of exclusive resource ownership prevent the use of overlapped recycling, or the loading of an application in two application pools simultaneously. Exlcusive ownership requires the use of non-overlapped recycling and the routing of all requests for that application to the same application pool. Also, you can run only one worker process for that application pool, which means that exclusive ownership does not work in a Web garden. One way to work around this is to write multithreaded applications, or use shared reads, which might eliminate the need for exclusively owned resources.

Recycling by Elapsed Time

You can configure an application pool to recycle the worker process, or worker processes, that are assigned to it at specified intervals. By default, recycling by elapsed time is enabled in IIS 6.0, with the elapsed time set to 29 hours. This default setting fits the recycling needs of applications that are problem-free, or that have flaws that cause problems gradually. Recycling worker processes at this interval refreshes applications often enough to correct problems that build up slowly, without creating the severe overhead that can be caused by closely spaced recycling.

Reset the elapsed-time interval for recycling a worker process if your tests or log records indicate that the application that the worker process is assigned to is encountering problems after a given period of uptime. Set the elapsed time to a shorter period of time if problems are building up in less than the default time interval of 29 hours.

Microsoft does not recommend recycling ASP.NET applications by elapsed time.

For information about how to use IIS Manager to configure a worker process to be recycled after a set elapsed time, see "Configure Application Pool Recycling" in "IIS Deployment Procedures" in this book. For information about how to configure a worker process to be recycled after a set elapsed time by using a command-line procedure or scripts, see the PeriodicRestartTime property in the "Metabase Property Reference" in IIS 6.0 Help.

Recycling by Number of Requests

You can configure an application pool to recycle the worker process, or processes, that are assigned to it whenever the worker process handles a specified number of requests since the last recycle. By default, recycling by number of requests is disabled in IIS 6.0. When this feature is enabled, the default is 35,000 requests.

Enable recycling by number of requests if your log records or tests indicate that an application you are deploying causes significant problems on your server, or encounters significant problems, after the application handles a certain number of requests. Then, for the worker process assigned to the application pool containing the unhealthy application, set the number of requests to be handled before the worker process is recycled.

For information about how to configure a worker process to be recycled after processing a set number of requests through IIS Manager, see "Configure Application Pool Recycling" in "IIS Deployment Procedures" in this book. For information about how to configure a worker process to be recycled after processing a set number of requests by using the command-shell or scripts, see the PeriodicRestartRequests property in the "Metabase Property Reference" in IIS 6.0 Help.

Recycling at Scheduled Times

To avoid recycling worker processes when server demand is heaviest, you can configure an application pool to recycle the worker process, or worker processes, that are assigned to it at a specified time of day, which is based on a 24-hour format. By default, recycling at a scheduled time is disabled in IIS 6.0.

You might need to schedule some, or all, of your applications to recycle worker processes at times of the day when the server load is light. Enable recycling at a scheduled time so that worker processes are rescheduled at times that best fit the load. Be careful to stagger the recycling of your application pools because allowing them to recycle at the same time can degrade the performance of your server during the recycle period.

For information about how to use IIS Manager to configure a worker process to be recycled at scheduled times, see "Configure Application Pool Recycling" in "IIS Deployment Procedures" in this book. For information about how to configure a worker process to be recycled at scheduled times by using a command-line procedure or script, see the PeriodicRestartSchedule property in the "Metabase Property Reference" in IIS 6.0 Help.

Recycling on a Virtual-Memory Threshold

A problem application might periodically increase virtual memory without subsequently releasing it. In this way, virtual memory can increase indefinitely. To limit the impact of increased virtual memory, you can set an application pool to recycle the worker processes that are assigned to it whenever virtual memory reaches a specified threshold.

By default, recycling on a virtual-memory threshold is disabled in IIS 6.0. When this feature is enabled, the default virtual-memory setting is 500 megabytes (MB). Enable recycling on a virtual-memory threshold and set a virtual memory threshold that prevents unacceptable degradation. Begin with a setting of 70 percent of available virtual memory.

For information about using IIS Manager to configure a worker process to be recycled after consuming a set amount of memory, see "Configure Application Pool Recycling" in "IIS Deployment Procedures" in this book. For information about how to configure a worker process to be recycled after consuming a set amount of memory by using a command-line procedure or scripts, see the PeriodicRestartMemory property in the "Metabase Property Reference" in IIS 6.0 Help.

Recycling on a Used-Memory Threshold

A problem application might indefinitely increase the amount of memory that it uses without releasing the memory. This is also known as an application memory leak. You can set an application pool to recycle the worker processes that are assigned to it whenever used memory, which is also called private memory, reaches a specified threshold.

By default, recycling on a used-memory threshold is disabled in IIS 6.0. When it is turned on, the default used-memory threshold is 192 MB. To limit the impact from an application that increases used memory over time, enable recycling on a used-memory threshold and set a threshold that prevents unacceptable degradation such as a memory-bound application that is unable to process requests. Initially, try a threshold of 60 percent of available memory.

For information about using IIS Manager to configure a worker process to be recycled after consuming a set amount of memory, see "Configure Application Pool Recycling" in "IIS Deployment Procedures" in this book. For information about how to configure a worker process to be recycled after consuming a set amount of memory by using a command-line procedure or scripts, see the PeriodicRestartPrivateMemory property in the "Metabase Property Reference" in IIS 6.0 Help.

Tuning Performance

When IIS is running in worker process isolation mode, you can tune the performance of your applications to conserve CPU and memory resources, and to add worker processes to application pools that need them. By setting the application pool properties for idle time-out, you can optimize the time that worker processes remain idle for each application pool, removing them from memory. Another way to conserve memory is to shorten the request queue length limit property for the worker processes in each application pool.

You can increase the number of worker processes that are available to an application pool by configuring a Web garden, which is an application pool that is served by more than one worker process. When a worker process is engaged, another worker process can continue to process requests, enhancing server performance. Finally, on a computer with more than one CPU, you can establish affinity between worker processes and specific CPUs, ensuring that applications are tied to processors in accordance with your priorities.

Managing Isolation and Performance

To help achieve high levels of application availability, you can assign fewer applications to each application pool, as low as one application per application pool. This increases isolation, protecting applications from each other. However, configuring fewer applications per application pool increases the total number of application pools. This results in greater CPU and memory usage, degrading server performance, and resulting in reduced request-processing throughput.

The performance impact of increasing the number of application pools on a computer varies based on the number of application pools that are running worker processes. If there are a large number application pools, but few worker processes are running, the impact is relatively small; if there are a large number application pools and many worker processes are running, worker processes can impact each other as they use up memory and CPU capacity, thereby negatively impacting performance.

The degree to which increasing application isolation causes performance degradation can only be determined by testing. You can test for the optimum level of isolation by doing the following:

Set the highest level of isolation that your configuration can support, and test with all application pools running simultaneously. Assess the results after using Performance Monitor to record requests processed per second, CPU usage, and memory usage. If performance is satisfactory, the test is complete; if performance is not satisfactory, proceed to Step 2.

If the results in Step 1 are unsatisfactory, reduce the isolation level by reducing the number of application pools, and then run the test again.

Continue Step 2 until you achieve satisfactory performance. In addition to reducing the number of application pools, you might need to remove applications from the server.

For information about isolating applications, see "Isolate Applications in Worker Process Isolation Mode" in "IIS Deployment Procedures" in this book. For information about assigning applications to application pools by using a command-line procedure or scripts, see the AppPoolId property in the "Metabase Property Reference" in IIS 6.0 Help.

Configuring Idle Time-out for Worker Processes

To conserve system resources, configure the idle time-out interval of an application pool to shut down its worker process, or worker processes, after a specified period of idle time. This reduces memory consumption and CPU overhead. This also helps you manage the resources on a Web server when the processing load is heavy, when identified applications consistently fall into an idle state, or when new processing space is not available. To preserve performance, as the number application pools running simultaneously on a server increases, the idle timeout setting should be decreased.

By default, idle time-out is enabled, and the default time-out period is 20 minutes. To automatically shut down worker processes as they become idle, configure a scheduled shutdown of the idle worker process, or worker processes.

For information about how to configure idle time-out by using IIS Manager, see "Configure Application Pool Performance" in "IIS Deployment Procedures" in this book. For information about how to configure idle time-out by using a command-line procedure or scripts, see the IdleTimeout property in the "Metabase Property Reference" in IIS 6.0 Help.

Configuring a Request Queue Limit

When an application pool receives requests faster than it can handle them, the unprocessed requests might consume all of the memory on the server, slowing the server and preventing other application pools from processing requests. This can happen when the queue size limit for the requests is large and legitimate requests are coming in at a rapid rate, or during a denial of service attack.

To prevent requests from consuming all the memory for an application pool, limit the size of the request queue for the application pool. To monitor and manage CPU consumption, you must enable CPU monitoring, gather data on CPU usage, and reduce the request queue limit when CPU consumption exceeds the specified limit.

For example, if you have a Web server that is capable of processing 10,000 requests per minute, and you have an application that can queue up 5,000 requests within that period of time, the application consumes 50 percent of the capacity of the server. You can configure IIS 6.0 to limit the number of requests to 2,000, reducing the potential memory consumption of the application and reducing the Web server capacity used by the application to 20 percent.

By default, request queue limit is enabled in IIS 6.0, and the default value is 1,000 requests. When resetting the default value, remember that a value that is too high can prevent other applications from having an equal share of the server resources and a value that is too low can cause the server to return 503 errors, or a disruption of service for the clients.

For information about how to configure a request queue limit by using IIS Manager, see "Configure Application Pool Performance" in "IIS Deployment Procedures" in this book. For information about how to configure a request queue limit by using a command-line procedure or scripts, see the AppPoolQueueLength property in the "Metabase Property Reference" in IIS 6.0 Help.

Managing ASP.NET and Request Queue Limit

Recycling worker processes that are serving ASP.NET applications requires that you restart under a request processing load. Starting the new worker processes under a load might cause requests to be rejected because the queue is too full. When this occurs, either increase the queue size limit or disable recycling.

For more information about ASP.NET-specific considerations for applications, see "Deploying ASP.NET Applications in IIS 6.0" in this book.

Configuring Web Gardens

To improve availability for a Web site or application, you can increase the number of worker processes servicing the application pool by implementing a Web garden, an application pool that uses more than one worker process on a single computer. This might be helpful if you have already configured a single-application application pool and need to improve availability.

Creating a Web garden for an application pool enhances performance by providing the following benefits:

Robust processing of requests. When a worker process in an application pool is tied up (for example, when a script engine stops responding), other worker processes can accept and process requests for the application pool.

Reduced contention for resources. When a Web garden reaches a steady state, each new TCP/IP connection is assigned, according to a round-robin scheme, to a worker process in the Web garden. This helps smooth out workloads and reduce contention for resources that are bound to a worker process.

Because Web gardens enable the use of multiple processes, all processes have their own copy of application state, in-process session state, caches, and static data. Web gardens are not advantageous for applications that depend on application state. Identify the standard relative performance in a Web garden before you decide whether Web gardens are the best solution for your server.

By default, the Web garden feature is disabled in IIS 6.0, and the default number of worker processes assigned to an application pool is set to one. You can enable Web garden functionality by setting the number of worker processes assigned to an application pool to a number greater than one.

For information about how to configure a Web garden by using IIS Manager, see "Configure Application Pool Performance" in "IIS Deployment Procedures" in this book. For information about how to configure a Web garden by using a command-line procedure or scripts, the MaxProcesses property in the "Metabase Property Reference" in IIS 6.0 Help.

Setting Processor Affinity on Servers with Multiple CPUs

On a multi-CPU server, you can configure application pools to establish affinity between worker processes and CPUs to take advantage of more frequent CPU cache hits. By using processor affinity, you can control processors when applications place demands on system resources. Processor affinity is used in conjunction with the processor affinity mask setting to specify the CPUs.

Use processor affinity on computers with multiple processors when it is necessary to continue processing an application that is tied to a subset of the hardware in such a way that transitions from one processor to another are minimized. By default, processor affinity is disabled in IIS 6.0, and the load is distributed across all available CPUs. On a server that is supporting multiple applications, you can enable processor affinity so that a processor is dedicated to each application.

For information about how to set processor affinity, see "Set Processor Affinity" in "IIS Deployment Procedures" in this book, or see the SMP Affinitized, and SMPProcessorAffinityMask properties in the "Metabase Property Reference" in IIS 6.0 Help.

Managing Application Pool Health

IIS 6.0 health-monitoring and management features support application availability by detecting problems with worker processes that are assigned to application pools, and by taking action to manage the problems. When IIS 6.0 is running in worker process isolation mode, you can detect the health condition of a specific application pool by enabling WWW service to ping a worker process that is assigned to it. Also, you can set features to take corrective action when an unhealthy condition occurs.

Generally, a healthy worker process responds to periodic pings that are sent by WWW service. If a worker process does not respond to the pings within the time interval specified by the PingResponseTime property, the WWW service determines the worker process to be unhealthy and triggers other health management features.

Consider using worker process health detection for the following reasons:

It allows IIS to determine whether each process has at least one thread available to work on requests, and then decide whether to pull new requests from HTTP.sys or to continue processing existing requests.

It allows the worker process to request recycles when Internet Server Application Programming Interface (ISAPI) extensions such as ASP.NET and ASP are identified to be unhealthy. The health detection feature uses the ability of a worker process to respond to a ping message. The worker process responds to a ping by requesting a recycle if one or more of the ISAPI extensions it has loaded is identified to be unhealthy.

Configuring Worker Process Pinging

Application pool health detection is the ability of the WWW service to detect that a worker process assigned to the application pool is in an unhealthy state by periodically pinging, or sending a ping message to, the worker process.

Optimizing Ping Intervals

You can specify a value for the ping interval by examining the potential amount of system resources that can be consumed by unhealthy worker processes over the interval (the default is 30 seconds). Then determine how long you can wait for system resources that unhealthy worker processes are using to be freed so that they are available to other worker processes.

If a worker process becomes unhealthy, the client does not receive a response until another worker process is started to replace the unhealthy worker process. This leaves the unhealthy worker process active without releasing the system resources used by the process. Over a period of time, the amount of system resources used by an unhealthy worker process can accumulate and affect the overall performance of the Web server.

For example, you might have an application that causes worker processes to become unstable. Over a five-minute period of time, the amount of system resources consumed by these unstable worker processes can consume Web server resources and affect the performance of other applications that are on the same Web server. You can configure IIS 6.0 to ping worker processes in that application pool to check the health of the worker processes every 30 seconds, which ensures that the unhealthy worker processes are shut down before system resources are consumed.

Set ping intervals to avoid false failure conditions caused by healthy worker processes that do not respond within the specified response time. You can check this by testing to ensure that the WWW service does not shut down a worker process that is still running, but is too busy to return the ping in the specified response time. If your tests indicate that your worker processes are shutting down because of false failure conditions, increase the ping response time, or alter the load on the worker process.

By default, worker process pinging is enabled in IIS 6.0. The default ping interval is 30 seconds, and the default ping response time is 60 seconds.

For information about how to configure worker process pinging by using IIS Manager, see "Configure Application Pool Health" in "IIS Deployment Procedures" in this book. For information about how to configure worker process pinging by using a command-line procedure or scripts, see the PingingEnabled, PingInterval, and PingResponseTime properties in the "Metabase Property Reference" IIS 6.0 Help.

Configuring Rapid-Fail Protection for Worker Processes

When WWW service detects that a worker process fails more than a set maximum number of times in a specified time period, it places the application pool that the worker process is serving in a rapid-fail state. Rapid-fail protection reduces processing overhead for unhealthy applications because the requests do not enter user-mode processing. As a result, applications that are running in other application pools are protected from the unhealthy application.

By default, rapid fail protection is enabled in IIS 6.0, with a maximum of 5 failures in a 10-minute interval. You can specify the threshold for placing an application pool in rapid-fail state by setting the maximum number of worker process failures that you want to allow over a specific period of time. Specify a threshold that allows IIS 6.0 to detect that a significant number of the worker processes in an application pool are failing and prevent system resources from being consumed.

For information about how to configure rapid-fail protection by using IIS Manager, see "Configure Application Pool Health" in "IIS Deployment Procedures" in this book. For information about how to configure rapid-fail protection by using a command-line procedure or scripts, see the RapidFailProtection, RapidFailProtectionMaxCrashes, and RapidFailProtectionInterval properties in the "Metabase Property Reference" in IIS 6.0 Help.

Configuring the Startup Time Limit for Worker Processes

The startup time limit specifies how long IIS will wait for a worker process to start servicing requests. By default, worker process startup time limit is enabled in IIS 6.0 with a default setting of 90 seconds. If 90 seconds is not long enough to allow the application to begin processing requests, then try a longer time interval.

For information about how to configure the startup time limit for worker processes by using IIS Manager, see "Configure Application Pool Health" in "IIS Deployment Procedures" in this book. For information about how to configure the startup time limit for worker processes by using a command-line procedure or scripts, see the StartupTimeLimit property in the "Metabase Property Reference" in IIS 6.0 Help.

Configuring the Shutdown Time Limit for Worker Processes

When IIS 6.0 detects that a worker process is unhealthy, IIS 6.0 marks the worker process for termination. The shutdown time limit specifies how long IIS waits until forcibly terminating the worker process when the worker process does not shut down automatically.

By default, worker process shutdown time limit is enabled in IIS 6.0 with a default of 90 seconds. If you have an accurate profile of requests, specify a shutdown time limit that is long enough to allow the worker process to complete any pending requests before shutting down.

For information about how to configure the shutdown time limit for worker processes by using IIS Manager, see "Configure Application Pool Health" in "IIS Deployment Procedures" in this book. For information about how to configure the shutdown time limit for worker processes by using a command-line procedure or scripts, see the ShutdownTimeLimit property in the "Metabase Property Reference" in IIS 6.0 Help.

Enabling Debugging for Application Pool Failures

Debugging a specific worker process that is serving an application pool helps you build high-availability applications. By default, debugging is disabled in IIS 6.0. When you enable debugging, the WWW service stops managing worker processes that fail to respond to a ping in the specified time period. Rather than terminating the application when a process fails to respond to a ping, IIS executes an action such as a process dump or an e-mail notification to alert you to the problem. You can then review the application to identify the cause of the failure.

For more information about how to enable debugging, see "Debug Application Pool Failures" in "IIS Deployment Procedures" in this book, or see the OrphanWorkerProcess, OrphanActionExe, and OrphanActionParams properties in the "Metabase Property Reference" in IIS 6.0 Help.

Configuring Application Pool Identity

Application pool identity is the user account that serves as the process identity for the worker processes that are servicing the application pool. Process identity is the account that a process runs under. Every Windows Server 2003 process has a process identity that is used to control access to resources on the system.

Application pool identity can be assigned to a predefined account. Predefined accounts are known as service-user accounts and they are created by the operating system. You can use the predefined NetworkService, LocalSystem, or LocalService accounts for the application pool identity.

In IIS 6.0 worker process isolation mode, application pools have a default identity of NetworkService. The NetworkService identity has minimal administrative credentials, which helps reduce the attack surface of your Web server. If you deploy applications that require a fixed worker process identity, you can change the application pool identity. For information about security and application pool identities, see "Configuring Application Pool Identity Settings" in "Deploying ASP.NET Applications on IIS 6.0" in this book.

For information about how to configure application pool identity by using IIS Manager, see "Configure Application Pool Identity" in "IIS Deployment Procedures" in this book. For information about how to configure application pool identity by using a command-line procedure or scripts, see the AppPoolIdentityType property in the "Metabase Property Reference" in IIS 6.0 Help.