Data Centers

Configuring and administering IIS 6.0

Making the move to Windows Server 2003 and IIS 6.0 means that you have to learn a few new tricks when configuring and administering IIS. Here's what you'll face.


Windows Server 2003 introduced some significant changes from Windows 2000 Server, and IIS 6.0 is a good example. Not only is IIS’s architecture considerably different in IIS 6.0, but the management interface is also changed. Many IIS configuration issues and methods are the same in IIS 6.0 as in IIS 5.0 If you're making the move to IIS 6.0, you need to understand the new architecture and how it affects IIS 6.0 management.

Choose your mode
IIS 6.0 provides two operating modes, IIS 5.0 Isolation Mode and IIS 6.0 Worker Process Isolation Mode. In IIS 5.0 Isolation Mode, all in-process applications run inside inetinfo.exe. Out-of-process applications run in separate instances of DLLHost.exe. Inetinfo.exe handles HTTP request queuing, IIS services (FTP, SMTP, NNTP, etc.), and worker processes. Svchost.exe runs the WWW service. The primary purpose for IIS 5.0 Isolation Mode is to mimic the behavior of IIS 5.0, and earlier versions, and provide compatibility for Web applications designed specifically for IIS 5.0 or earlier.

IIS 6.0 Worker Process Isolation Mode, also called native mode, provides better performance, reliability, and fault tolerance. In native mode, the kernel-mode driver http.sys handles all HTTP request processing and queuing. Inetinfo.exe handles IIS administration and configuration as well as the IIS services, including SMTP, NNTP, and FTP. Svchost.exe handles the WWW service, and multiple instances of w3wp.exe handle worker processes.

Separating worker processes in this way isolates those worker processes from the core IIS services for better reliability overall and better recoverability for individual processes. This process isolation, combined with the fact that the core IIS services prevent third-party code from being loaded into them, means an errant Web application will have a tough time crashing the WWW service and bringing down the server.

In a clean installation of IIS 6.0, native mode is the default mode. A system upgraded from a previous IIS 6.0 installation assumes the mode of the previous installation. Systems upgraded from IIS 5.0 or IIS 4.0 run in IIS 5.0 Isolation Mode to provide compatibility for the existing Web applications on the server.

One aspect of managing an IIS 6.0 server is setting the mode in which the server runs. For example, you might be installing a Web application that will not run in native mode and need to switch the server to IIS 5.0 Isolation Mode. Or, maybe you upgraded an existing server and now want to switch it from IIS 5.0 Isolation Mode to native mode. Note that the server as a whole runs in a given mode; you can’t run specific sites on the server in different modes.

To configure IIS 6.0’s operation mode, open the Internet Information Services Manager from the Administrative Tools folder, or run %systemroot%\system32\inetsrv\iis.msc. When the IIS console opens, right-click the Web Sites branch in the left pane and choose Properties, and then click the Service tab. When you do, you'll see the screen shown in Figure A.

Figure A
You can set the operating mode here.


The option Run WWW Service In IIS 5.0 Isolation Mode, if selected, configures the server to run in IIS 5.0 Isolation Mode. Clear this option if you want to run the server in native mode.

Configuring HTTP compression
While you have the Service tab displayed, you might also want to configure compression settings for the server. IIS 6.0 supports HTTP compression, which enables it to compress static files as well as dynamic application responses to reduce the amount of bandwidth required to service the requests. IIS first verifies that the requesting client supports compression. If so, and the request is for a static file, IIS checks its cache to determine if a compressed copy of the file resides in the cache.

If the file resides in the cache, IIS returns the cached copy to the client. If the requested file has not already been cached, IIS compresses it, places it in the cache, and serves it to the client. If the client has requested dynamic content, IIS compresses the generated response and returns it to the client but does not cache the response. The result is reduced bandwidth utilization and generally better browsing performance for the client, particularly over a slow connection.

HTTP compression does impose some CPU load on the server, but as long as your server’s CPU load isn’t maxed out (Microsoft recommends 80% or less), you should be able to safely implement compression without a negative performance impact on the server. To enable compression, select the Compress Application Files and Compress Static Files options on the Service tab of the Web Sites container. You also must specify the folder to contain the compressed files cache, which defaults to %windir%\IIS Temporary Compressed Files.

You can change the location if needed to accommodate security or capacity issues. You can also impose a limit on the cache, if needed, to control disk usage. Click OK to apply the changes. See the IIS console Help topic Utilizing HTTP Compression to learn how to evaluate HTTP compression with the Performance console.

Jump into the application pool
Separating applications into multiple application pools not only can improve performance but also improves server and site reliability. If you're running in native mode, you can create application pools and assign applications to those application pools as needed.

The first step is to create an application pool. Open the IIS console, right-click the Application Pools branch, and choose New, Application Pool to open the Add New Application Pool dialog box. If you don’t see the Application Pools branch, then you're not running in native mode.

Enter a name for the application pool to uniquely identify it. You can create the new application pool using the default settings or use an existing application pool as a template. Choose which option to use and then click OK to create the application pool.

Next, configure the application pool settings. Expand the Application Pools branch, right-click the application pool, and choose Properties. The Recycling tab, shown in Figure B, of the application pool’s property sheet lets you configure how IIS handles worker process recycling for the application pool. You can have IIS recycle the worker processes after a given period of inactivity, after a specific number of requests, or at scheduled times. You can also configure IIS to recycle worker processes in the application pool when the process has consumed a specific amount of privately allocated physical memory, virtual memory, or both. Enabling IIS to recycle worker processes helps ensure that failed worker processes are terminated and their resources recovered.

Figure B
The Recycling tab


The Performance tab, shown in Figure C, offers several options to configure performance values and monitoring. You can configure IIS to shut down idle worker processes after a specified idle time and set a limit on the number of requests that the pool can handle. Terminating idle worker processes recovers resources for the system and limiting requests prevents the server from becoming overloaded by a large number of requests. (If the limit is reached, IIS returns a 503 error to the client.)

Figure C
The Performance tab


You can also enable CPU monitoring from the Performance tab. IIS monitors worker processes and terminates those that exceed the specified CPU usage. IIS will either take no action or shut down the worker process, depending on the action you specify. Setting CPU limits ensures that a worker process will not hog the processor and potentially hang the system.

The last option on the Performance tab lets you set the maximum number of worker processes allowed in a Web garden, which is an application pool that uses more than one worker process. A Web garden can provide better request processing by providing multiple application pools to handle requests. Requests are handed out to worker processes in the Web garden on a round-robin basis to distribute the load across the garden.

This is similar in concept to a Web farm, which uses multiple Web servers to service client requests, but at a much more granular level. Web farms and Web gardens are not the same thing, but you can certainly use them together. As requests come into the Web farm they are passed on to a particular server. At the server, the request is then passed on to a particular worker process.

The Health tab, shown in Figure D, of the application pool’s properties lets you configure options that enable IIS to monitor worker process health and set time limits on startup and shutdown for the worker processes. You can enable pinging and configure a ping interval, which allows IIS to ping worker processes to determine if they are still responsive. Those worker processes that fail to respond are terminated and replaced by a new worker process.

Figure D
The Health tab


Rapid-fail protection, also configurable from the Health tab, allows IIS to disable an application pool if it experiences a specified number of failures in a given period of time. Use the Startup Time Limit option to specify the number of seconds in which a worker process must start or be terminated. Use the Shutdown Time Limit option to specify the allowed shutdown period for the worker process before it is recycled.

The Identity tab, shown in Figure E, lets you specify the security account under which the application pool operates. You can choose from Network Service, Local System, and Local Service, or you can choose the Configurable option and specify an existing account and password on the system for the application pool to use. Which option and/or account you choose depends on your security infrastructure and security requirements of the application pool.

Figure E
The Identity tab


Another change you might want to make is to assign an application, such as a particular virtual directory or Web site, to a specific application pool. To do so, right-click the Web site or virtual directory and choose Properties. Click the Virtual Directory, Directory, or Home Directory tab (depending on the object type), and choose the application pool from the Application Pool drop-down list; then click OK.

Limiting connections and bandwidth
IIS 6.0 supports bandwidth throttling and connection limiting for individual Web sites, and you can also set global properties to limit bandwidth usage and connections. Limiting the number of connections and/or bandwidth used by the site helps you limit the site’s impact on the server, and limiting the server helps you manage the server’s impact on your network and available bandwidth.

To limit these at the server level, open the IIS console, right-click the Web Sites branch, and choose Properties. Click the Performance tab and use the Bandwidth Throttling group of controls shown in Figure F to set the maximum bandwidth in kbps for all sites on the server as a whole.

Figure F
You can control bandwidth and number of connections.


Use the Web Site Connections group to either allow an unlimited number of connections or limit the server to a total number of connections. To set these properties for a site, right-click the site and choose Properties, then click Performance. The available options are the same as for the server.

Site backup, migration, and recovery
Another big change in IIS 6.0 over IIS 5.0 is a switch to XML for storing the configuration metabase. By switching to XML, Microsoft’s IIS development team made it easier to back up sites and servers, restore them, and migrate sites from one server to another. To back up a specific site, open the IIS console, expand the Web Sites branch, right-click the site, and choose All Tasks, Save Configuration To A File. In the resulting dialog box, enter a file name for the configuration file (add the XML extension, as IIS does not add it for you), specify a path (the default is %windir%\system32\inetsrv), and optionally protect the file with a password. Click OK to create the configuration file.

It’s relatively easy to restore a site from an XML backup. Right-click the Web Sites branch and choose New, Web Site (from file) to open the Import Configuration dialog box. Browse to and select the XML file containing the site’s configuration. Click Read File, then choose the site from the list and click OK. If the site already exists on the server, IIS asks if you want to create a new site or replace the existing one. Choose the appropriate action and click OK. Then, restore the site content, if needed.

The process for backing up and restoring all sites is essentially the same—you simply accomplish it from a different level in the console. To back up all sites, right-click the Web Sites container and choose All Tasks, Save Configuration To A File. Specify the file name and path, optional password, and click OK. To restore from the backup, right-click the Web Sites container and choose New, Web Site (from file). Restore each site separately as I explained above.

In many situations you will want to back up the entire server’s configuration, not just the Web Sites branch. IIS automatically creates an initial backup of the server’s configuration and then periodically creates additional automatic backups. You can create your own backups at critical times, such as just prior to installing new software on the server.

Open the IIS console, right-click the server, and choose All Tasks, Backup/Restore Configuration to open the Configuration Backup/Restore dialog box, which lists all of the current backups. Click Create Backup to open the Configuration Backup dialog box, enter a name for the backup, optionally encrypt it with a password, and click OK. IIS stores the backup in the %windir%\system32\inetsrv\MetaBack folder. If you need to restore a particular configuration, right-click the server and choose All Tasks, Backup/Restore Configuration. Select a backup and click Restore.

Configuring Web service extensions
The Web Service Extensions branch of the IIS console lets you configure whether specific Web service extensions are allowed or prohibited. For example, on a default installation, Active Server Pages are enabled but all unknown ISAPI and CGI extensions are prohibited, as are Server Side Includes and WebDAV. To configure extensions, open the IIS console, expand the server, and click the Web Service Extensions folder. When you do, you'll see the screen shown in Figure G.

Figure G
You can allow or prohibit specific Web service extensions.


The right pane then displays the installed extensions and their states (either Prohibited or Allowed). You can right-click an extension and choose either Allow or Prohibit to change its state. You can also choose an extension and click the Allow or Prohibit button. To view the files associated with a particular extension, select the extension, and click the Properties button; then click the Required Files tab. You can allow or prohibit specific files for the extension.

To add a new Web service extension and either allow or prohibit it, click the Add a New Web Service Extension link. Enter a name for the extension, click Add, and choose files fro the extension, then click OK. You can allow or prohibit the custom extension as described previously.

Other management tasks
Most of the other tasks you will routinely perform on a Windows Server 2003 IIS server are the same as for IIS 5.0 in Windows 2000 Server. For example, creating sites and configuring site properties (other than application-pool related properties) is essentially the same. You’ll find the properties on the same tabs of the site’s or server’s property sheet.

One additional configuration task which I haven’t covered in detail here is setting up Background Intelligent Transfer Service (BITS) for the server. BITS enables file uploads and downloads to be resumed after a connection disruption occurs without restarting the file transfer. If you’re interested in using this feature on your server, check out the properties on the BITS Server Extensions tab of a site’s properties and the Help documentation to learn more about BITS.

Editor's Picks