IIS 6.0 Features

In "IIS Overhauled in Version 6.0," April 2003, http://www.winnet
mag.com, InstantDoc ID 38285, I describe Microsoft Internet Information Services (IIS) 6.0 installation and the Web server's new architecture. IIS 6.0 also has a surprising number of new features. A handful of these features are so interesting that they capture nearly all the attention. In this second installment of my two-part look at IIS 6.0, I review a couple of these "stars" but also shine some light on a variety of IIS 6.0's lesser-known, but nevertheless significant, improvements.

Security
A peculiar thing happens at Microsoft from time to time. The company gets fed up with a problem in one of its products and solves it. For example, after releasing Windows NT 4.0, Microsoft was hammered with stability complaints. When the company released Windows 2000, the OS was praised for out-of-the-box stability. IIS 5.0, which is installed by default on Win2K servers, is a mammoth security risk until properly secured. IIS 6.0 isn't installed by default, and when you do install it, the Web server renders only static content. Thus, IIS 6.0 presents a much-reduced security risk, even if problems with IIS 6.0 application engines and components crop up later. Additionally, Windows Server 2003 has a new group policy: Prevent IIS installation. You can use this policy to prevent Windows 2003 from installing IIS 6.0 on servers in an Active Directory (AD) forest that aren't intended to be Web servers. The policy will help prevent rogue and possibly insecure IIS servers from popping up on the network. Note that this policy works only on Windows 2003 servers for the time being and won't prevent Windows XP Professional Edition or Win2K from installing IIS 5.0.

Of course, the fact that IIS 6.0 doesn't render dynamic content out of the box automatically creates the second most frequently asked question about IIS 6.0: "Why isn't my server delivering Active Server Pages (ASP)?" (As I mentioned in "IIS Overhauled in Version 6.0," the most frequently asked question is, "Can IIS 6.0 be installed on Win2K Server?" The answer is no.) To permit programs to run under IIS 6.0, you use a new feature named Web service extensions. (The name implies some kind of relationship with XML Web services, but no connection exists.)

To add or enable a Web service extension for a program, open IIS Manager (formerly Internet Services Manager—ISM); select Web Service Extensions, as Figure 1, page 70; shows, and click Add a new Web service extension to start a wizard that creates a new rule. Assign the rule a name, then navigate to the executable you want to allow. You can use the iisext.vbs script in system32inetsrv to manipulate Web service extension settings.

In Figure 1, notice the Web service extensions All Unknown ISAPI Extensions and All Unknown CGI Extensions. By default, these two entries are set to Prohibited, meaning that unless you specifically permit an application to run on IIS 6.0, it won't. If a user requests a file that isn't mapped to an enabled process, IIS 6.0 returns HTTP Error 404 File or directory not found to the user and records 404.2 Denied due to lockdown policy in the W3SVC log. The 404.2 and other substatus codes are available in IIS 6.0 as an option for the W3SVC log file to aid in troubleshooting. (Substatus codes exist in IIS 5.0 and Internet Information Server—IIS—4.0, but IIS doesn't record them in the W3SVC logs. You can route them to custom error pages for special processing.) The IIS 6.0 substatus codes are helpful because they provide details about the problem: for example, 403.18 Forbidden — Cannot execute request from this application pool; 403.20 Forbidden: Passport Login failed; and 404.3 Not Found - Denied due to MIMEMAP Policy. These and other errors are also mapped to a custom error page that doesn't reveal the substatus code to the user, so potential intruders can't exploit the information.

Another security enhancement is the ability to designate a Cryptographic Service Provider (CSP) that helps integrate hardware-based Secure Sockets Layer (SSL) accelerators with IIS 6.0. Moving the task of encryption from the server's general-purpose CPU to dedicated hardware optimized for this purpose can greatly improve performance. To designate a CSP, select the Select cryptographic service provider (CSP) for this certificate check box when you use the IIS Certificate Wizard to create a certificate request. You will then see a list of Available Providers from which you can choose. If you're using an encryption device, the vendor will provide the name of the appropriate CSP.

The Metabase
In IIS 6.0, Microsoft has abandoned the binary file structure of the IIS 5.0 and IIS 4.0 metabase that chained the metabase to the server on which it was created. The IIS 6.0 metabase consists of a pair of XML files: Metabase.xml contains the settings for the IIS 6.0 server, and mbschema.xml contains the metabase schema. A new feature in IIS Manager lets you save a copy of the metabase by right-clicking Web Sites and selecting All Tasks, Save Configuration to a File. You then provide a filename and path for the metabase backup. When you save the metabase in this way, IIS 6.0 uses the machine key of the system to encrypt some metabase parts. Consequently, the metabase backup is useful only on the machine that created the backup. However, you can also select the Encrypt configuration using password check box to encrypt the exported metabase file with a password that you provide. When you do so, IIS 6.0 substitutes the password you provide for the machine key and you can import the metabase file to another server by providing the same password. If you want to automate metabase backup, you can use the iisback.vbs and iiscnfg.vbs utilities in windowssystem32.

In some cases, you might want to save the configuration of an application pool, Web site, or virtual directory without saving the entire metabase. To do so, right-click the object whose configuration you want to save and again select All Tasks, Save Configuration to a File, as Figure 2 shows. If you plan to import the settings to another server, provide a password to encrypt the file.

If you right-click Application Pools, Web Sites, or an individual Web site and select New, Application Pool (from file); New, Web Site (from file); or New, Virtual Directory (from file), you can create a new application pool, Web site, or virtual directory from a saved file. So, for example, you can create a virtual directory once, use Save Configuration to a File to export the virtual-directory settings, then use New, Virtual Directory (from file) to import the settings into multiple Web sites. In other words, you can create a template configured exactly as you want and use it to create or configure new sites as well as restore settings.

Another advantage of IIS 6.0's new metabase portability is that it makes possible a creative upgrade technique. If you don't want to do an in-place upgrade from Win2K/IIS 5.0 to Windows 2003/IIS 6.0, you need to solve the problem of how to migrate the nonportable metabase from IIS 5.0 to the new IIS 6.0 server. The answer is to create your new Windows 2003 server, make a solid backup of the Win2K server, then upgrade the Win2K server to Windows 2003. You can save the resulting metabase with a password, then import it to the new server. You'll need to make some adjustments to the metabase to allow for the new server's IUSR account and other changes, but at least portability is now possible.

Because IIS 6.0's metabase is a typical text file containing well-formed XML, you can now open and edit the metabase with a text editor such as Notepad. In some cases, when you change the IIS 5.0 or IIS 4.0 metabase, you must restart IIS. Doing so can take a while on systems with many Web sites and can result in significant downtime for servers that have a large metabase, such as an ISP's servers. To address this problem, IIS 6.0 has an edit-while-running feature, which you enable by selecting the Enable Direct Metabase Edit check box in the Properties dialog box for the server in IIS Manager. When the check box is selected, as Figure 3 shows, you can open the metabase with Notepad, paste in a virtual directory, and close the file. IIS 6.0 will pick up the change almost immediately without requiring a restart.

Of course, now that you can edit the metabase directly, you can easily incapacitate your server or application. Thus, Microsoft created the metabase version history folder system32inetsrvhistory. Every time you make a change to the metabase or restart IIS 6.0, IIS 6.0 makes a backup of the old metabase to the history folder.

Fun with IIS Manager
In any major product upgrade, you expect to find some new cool features in the UI. IIS 6.0's IIS Manager has a couple of changes, but surprisingly few.

One change in the UI is simple but helpful. If you right-click a folder in IIS Manager, you can select Permissions, which opens the folder's Security tab. You can use this tab to change the folder's NTFS permissions without leaving IIS Manager. This feature will save a few thousand work hours this year worldwide.

Another change involves the property page that's displayed when you right-click a Web site, select Properties, go to the Directory Security tab, and click Edit under Secure Communications. You use the Secure Communications property page to configure SSL, certificate trust lists (CTLs), and client certificates. In IIS 5.0 and IIS 4.0, you can't access this property page unless you've installed a certificate on the Web site. This restriction is interesting because configuring CTLs and client certificates technically doesn't require a certificate installed on the server. In other words, the only reason you need a certificate to use these features in IIS 5.0 is that the UI requires it. IIS 6.0 fixes this incongruity—you can access the property page and use its features without having to install a certificate on the Web site.

Allowing access to CTLs and client certificates without requiring a Web site certificate fixes one problem but causes another. The Secure Communications property page lets you enable the Require secure channel (SSL) feature. However, because you don't need a certificate to reach this page in IIS 6.0, you could set a Web site or directory to require SSL even though the Web site isn't SSL-enabled. If you do so, users will receive the message 403.4 Forbidden: SSL is required to view this resource. Don't be fooled into thinking that your ability to enable the Require secure channel (SSL) setting for a Web site or directory means that that Web site or directory can negotiate SSL.

ISAPI Interceptors
Those of you familiar with IIS 5.0's and IIS 4.0's Internet Server API (ISAPI) filters might also be familiar with their shortcomings. They're difficult to build, and because they run in the Inetinfo process, making mistakes when building them can cause disasters. An ISAPI filter that has an exception that buggy code caused can halt IIS. In addition, ISAPI filters don't have all the capabilities of regular ISAPI DLLs. Nevertheless, ISAPI filters are useful because they're the only mechanism in IIS 5.0 and IIS 4.0 that can run code that you want to run against all traffic coming to the Web server or a Web site.

IIS 6.0 offers a new, more flexible mechanism known as ISAPI interceptors—also called wildcard applications—to provide services that ISAPI filters often deliver. You can configure these applications by right-clicking Web Sites in IIS Manager, selecting Properties, going to the Home Directory tab, then clicking Configuration. On the Mappings tab of the resulting Application Configuration dialog box, which Figure 4 shows, you can insert one or more ISAPI DLLs as wildcard applications. IIS 6.0 will invoke these applications for every request it receives. You can also configure these settings at the individual Web site or directory level. Because these ISAPI interceptors are typical ISAPI applications, they have the full range of capabilities that any ISAPI application has, including access to message bodies, not just the headers that ISAPI filters have access to.

A wildcard application can do whatever the developer wants it to do, including URL customization, authentication, specialized logging, intrusion detection, and content creation. When the wildcard application completes its processing, it hands off the request to the intended processing engine (such as asp.dll for an ASP page), which then processes the request. The wildcard application could also redirect the traffic to any page in the same application pool by invoking the new ExecuteURL capability available to ISAPI applications.

This new ISAPI interceptor capability opens several doors for creative application design. For example, IIS 6.0 implements its new URL authorization capabilities as the ISAPI interceptor urlauth.dll. URL authorization lets IIS 6.0 authorize access to a URL based on rules such as group membership, state of residence, or any other attribute associated with the user in a database or in AD. For more information about ISAPI interceptors and URL authorization, see the IIS 6.0 Help files.

Logging
A server's logging capabilities rarely get top billing, but you rely on them for the day-to-day management and monitoring of a server. IIS 6.0 provides several significant logging enhancements, but unfortunately, you still can't record W3SVC log events in local time.

In IIS 6.0, the code for recording logs has been moved into http.sys, which runs in the kernel. This setup writes logs more quickly and prevents contention among worker processes for one log file. In some cases, http.sys encounters an error that it should but can't record in a Web site's logs. For example, a worker process might be recycling, preventing http.sys from processing a request, or a user might make a request to connect to the server but send only part of the information IIS requires. Http.sys records these events in a new log file called httperr.log.

Httperr.log is vital in troubleshooting and performance-tuning IIS 6.0. By default, the log is in system32logfiles, but you can change the location by adding to the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesHTTPParameters registry subkey a string value named ErrorLoggingDir that contains the full path to the target folder. Items you'll find in the log include all 503 errors, idle connection timeouts, errors incurred while parsing the URL, and the last 10 requests submitted to a failed application pool.

IIS 6.0 also sports a feature called binary logging that, when enabled, writes to one log file in a binary format all the logging information for a Web site. To turn on binary logging and create a centralized binary log file ending in .ibl, you set the metabase entry W3SVCC/CentralBinaryLoggingEnabled to true (1). This feature could prove useful to ISPs that host 1000 or more Web sites per box. If each Web site creates a log file each day, the resulting number of log files quickly becomes astronomical. The recently released Microsoft Log Parser 2.0 tool can read the binary log file and create reports. You can obtain the tool at http://download.microsoft.com/download/iis50/utility/2.0/nt5xp/en-us/setup.exe. (Log Parser can also read and report on the httperr.log file mentioned earlier.)

If you want to write log files in a language other than English, you can also tell http.sys to use UTF-8 instead of ASCII for the log-file character set. To do so, right-click the local computer in IIS Manager to open the Properties dialog box and select the Encode Web logs in UTF-8 check box.

IIS has long let you specify in which folder on the local server you want to store log files. However, although IIS 5.0 and IIS 4.0 IIS Manager let you enter the Universal Naming Convention (UNC) pathname of a remote server as the location for log files, the Web server wouldn't actually store the files on a remote server. IIS 6.0 supports a UNC pathname for the log-file directory.

Site ID Generation
A number, not a name, uniquely identifies Web sites to IIS. When you create a new Web site in IIS 5.0 and IIS 4.0, the Web server gives that Web site the next available number in sequential order (i.e., the Web server gives the default Web site the number 1 and subsequent Web sites that you create the numbers 2, 3, and so on). You need to know the site ID number to access the site's set of log files, which has a path that ends with W3SVCsiteIDnumber. If you have more than one site, you can't tell by looking at the log-file folder names which log-file folder belongs to which Web site. You also need the site ID number for any serious scripting or metabase modifications because specifying the Microsoft Active Directory Service Interfaces (ADSI) path to a metabase key often involves specifying the correct ID.

Nevertheless, site ID numbers aren't obviously visible in IIS 5.0 and IIS 4.0 IIS Manager. To remedy this situation, IIS 6.0 IIS Manager has a new Identifier column that lists the site ID number. You might be surprised to see that your IIS 6.0 site ID numbers are large, even if you have only two or three sites. The first site I created had the site ID 387660891 (and the path W3SVC387660891). IIS 6.0 doesn't number sites sequentially—it uses a formula based on the site name. This approach can be useful in a Web farm in which you want identical Web sites, including identical site ID numbers.

You might have scripts or utilities that are dependent on the sequential numbering system for site IDs. To disable the new numbering system and use the sequential system, open the HKEY_LOCAL_MACHINESOFTWAREMicrosoftInetMgrParameters registry subkey, create a REG_DWORD value named IncrementalSiteIDCreation, and set it to 2. This subkey isn't present by default.

Asynchronous CGI Processing
IIS 5.0 and IIS 4.0 run Common Gateway Interface (CGI) processes synchronously, which essentially means that only one thread can access a CGI process at a time. Thus, IIS 5.0 and IIS 4.0 CGI doesn't scale well. IIS 6.0 runs CGI processes asynchronously, so the thread that invokes a CGI application doesn't just sit and wait for the CGI process to return information. Asynchronous CGI will improve the performance of IIS servers running CGI Web applications and opens the door for more CGI-based applications to perform mission-critical tasks on IIS.

Pass-Through Authentication for Virtual Directories
Microsoft had promised pass-through authentication for remote virtual directories for some time, and the company has finally come through. IIS 5.0 and IIS 4.0 use one username and password to access remote content in a virtual directory that's mapped to a UNC pathname. Funneling all access to a remote server through one user account makes applying granular security on the remote system impossible. In addition, restrictions built into Win2K limit the amount of traffic you can run over one pathname. (For more information about using UNC pathnames with Win2K, see the Microsoft article "IIS Runs Out of Work Items and Causes RPC Failures When Connecting to a Remote UNC Path" at http://support.microsoft.com/?kbid=221790.) IIS 6.0 solves these problems.

IIS 5.0 and IIS 4.0 can also have difficulty receiving file-change notifications from the remote server. Microsoft worked hard on the file-change-notification problem in Windows 2003 and has improved the method IIS 6.0 uses to check for file changes. By default, IIS 6.0 checks for changes every 5 seconds instead of waiting on file-change notifications. This approach improves reliability but might not scale as well as the previous technique, so you can configure the server to use file-change notifications if you prefer. Also, you can now configure virtual directories to pass user credentials through to the remote server. These and other Windows 2003 improvements, such as constrained delegation, not only help with security but with implementing network storage devices and Storage Area Networks (SANs).

Bandwidth Throttling
IIS 5.0 and IIS 4.0's Performance tab in the Properties dialog box lets you enable bandwidth throttling and specify the maximum network use for the Web site. However, this feature doesn't work well because IIS 5.0 and IIS 4.0 can't actually manage the server's NICs. When you first enable bandwidth throttling on an IIS 6.0 Web site, Windows 2003 automatically installs the QoS Packet Scheduler, which interfaces with IIS. The QoS Packet Scheduler enables Quality of Service (QoS) capabilities for the server, so Windows 2003 temporarily stops all network services during the installation. After you configure the QoS Packet Scheduler, IIS has the driver it needs to make bandwidth throttling of Web sites a real possibility for the first time—which is good news for ISPs. The minimum restriction you can set is 1024 bytes per second. You should check that your NIC is on the Windows 2003 Hardware Compatibility List (HCL) because only more recent hardware will support the QoS functions.

To configure the QoS Packet Scheduler, you might first need to create a Group Policy console. Click Start, Run, then type

MMC

and click OK. Click Console, Add/Remove Snap-in, Add. Select Group Policy Object Editor, then click Add, Finish, Close, OK. Now you can expand Local Computer Policy, Computer Configuration, Administrative Templates, Network to display the QoS Packet Scheduler object, as Figure 5, page 73, shows. Installing the QoS Packet Scheduler applies to the entire system some defaults that might affect IIS bandwidth throttling. For example, by default, the QoS Packet Scheduler limits the system to 20 percent of available bandwidth. Consequently, you would need to configure IIS to use less than 20 percent of your bandwidth unless you adjust the QoS Packet Scheduler's Limit reservable bandwidth setting, which Figure 5 shows.

Different Default Settings
IIS 6.0 has some default settings that are different from those in IIS 5.0 and IIS 4.0. For example, the default setting for connection timeouts has been reduced from 900 seconds to 120 seconds. Also, the EnableParentPaths setting is turned off by default. Some of the new settings that might affect server performance are as follows:

I'm now at the end of a two-part saga about IIS 6.0, and I still haven't covered all the Web server's features. I didn't mention the redesigned Administrative Web Site that Windows 2003 installs—complete with certificate for SSL—upon request (by default in Windows 2003, Web Edition). I also left out some big-name features such as Passport Authentication and improvements in Digest Authentication. Instead, I reviewed some of the blockbuster features as well as a few of the lesser known capabilities to give you an idea of the depth of the changes in IIS 6.0. In many ways, IIS 6.0 is stealing the Windows 2003 show—and in my opinion, it deserves center stage.