Windows 2000's (Win2K's) Microsoft Internet Information Services (IIS—formerly Internet Information Server) 5.0 includes many new Internet features. Changes under the hood make the new IIS more reliable than previous versions and improve the way IIS 5.0 manages applications and integrates with other technologies.
The first thing I noticed about the most recent IIS is that it's part of Windows 2000's (Win2K's) Web and Application Services, making installation fast and painless. You don't need to purchase add-on software—you can install Web Services as you would any Win2K component. (The installation process is identical to an IIS 4.0 installation from the Windows NT 4.0 Option Pack.) During Win2K installation, select Internet Information Services from the installation options under the Win2K Components list, then click Details. After you select your desired components (including IIS), click Next. After Win2K completes the installation and reboots, you can begin to use IIS.
The Internet Service Manager (ISM), which Microsoft introduced in IIS 4.0, is still present. You can access the ISM under Start, Programs, Administrative Tools. When you open the new ISM, you'll see a familiar interface. The new ISM's similarity to its predecessor greatly reduces the learning curve. The folder structure is the same as in IIS 4.0, except that IIS no longer loads Microsoft Transaction Server (MTS) as part of the ISM tree structure. When you install IIS 4.0 from the NT 4.0 Option Pack, the software forces you to also install MTS. Web Services doesn't include MTS; Win2K has folded MTS's features into COM+, which installs with Win2K and is part of Web and Application Services.
You'll notice changes in the Microsoft Management Console (MMC) toolbar and menus as you begin to work with the ISM and other MMC tools. For example, the NT 4.0 MMC toolbar has icons to launch NT management tools (i.e., Key Manager, Performance Monitor, Event Viewer, Server Manager, and User Manager). The Win2K MMC doesn't need these icons because you can load these management function tools as MMC snap-ins and provide direct, fast access at any time.
Managing Web Services
Working with Win2K is tricky because so many things look familiar but are slightly different from NT 4.0—sometimes just different enough to cause a lot of frustration. Although a majority of the tabs in the new ISM interface remain the same as in the IIS 4.0 ISM, several of the tabs in the new interface have changed.
You can use the WWW Service option on the Master Properties sheet to set properties for a Web server. From the ISM, right-click the server name, then select Display Properties. Select WWW Service from the Master Properties drop-down list, then click Edit. The software will display the WWW Service Master Properties sheet, which Screen 1 shows.
At first glance, the Web Site tab looks identical to the same tab in IIS 4.0. However, notice the HTTP Keep-Alives Enabled check box in the Connections section. In IIS 4.0, this option appears on the Performance tab.
The Performance tab has also changed from IIS 4.0. This tab, which Screen 2 shows, offers a new option for limiting CPU utilization. The Enable process throttling option affects only out-of-process applications. After you select the Enable process throttling check box, you can enter the maximum percentage of CPU usage for out-of-process applications. If an application exceeds the specified amount, IIS writes an event to the event log. If you select the Enforce limits check box, Web Services will enforce the CPU limit according to one of three different levels:
- Level 1—Total processor use exceeds the limit set. IIS writes an event to the Win2K event log.
- Level 2—Processor use exceeds 150 percent of limit. IIS sets the CPU priority to Idle for all out-of-process applications on the selected Web site.
- Level 3—Processor use exceeds 200 percent of limit. IIS stops all out-of-process applications on the selected Web site.
Process throttling is most useful for servers that run multiple Web sites (not simply multiple virtual directories). Web Services sets the CPU limit for a 24-hour period and helps you keep out-of-process applications from consuming your CPU. When a site reaches the CPU limit, the limit stays in place until the 24-hour period expires, then Web Services resets the limit. Again, this restriction lets you control only out-of-process applications.
The Home Directory tab, which Screen 3 shows, also contains a few changes. Most of the changes are label (rather than process) changes, except for the addition of the Script source access check box. When you select this option, users have permission to access script files, such as Active Server Pages (ASP) files. (Most administrators rely instead on Microsoft FrontPage and NTFS to give developers access to application source code.) The Script source access option is available only when you also select either Read or Write access. The Execute Permissions option in the Application Settings section has changed, too. Instead of selecting from radio buttons at the bottom of the Home Directory tab, you now select from a drop-down list. The available options are the same as in IIS 4.0, except that Execute is now Scripts and Executables in the drop-down list. Application Protection (the other major option in this tab) deals with the application protection level, which I discuss later as part of "ASP Applications."
The options in the Directory Security tab, which Screen 4 shows, changed slightly. The Secure communications section now has three buttons to manage certificates and the Secure Sockets Layer (SSL); these three buttons replace the Key Manager button. You now click the Edit button to configure the server's SSL. Web Services also provides many new security options. You can run a Permissions wizard to define the permissions for a virtual directory. The new Win2K Kerberos security system opens the door for flexibility in handling Web security, and support for Digest Authentication enables advanced site security. For more information about Web Services security, see "Web Services's New Security Features," November 1999.
Microsoft left the Custom Errors tab unchanged. However, the location of the error message files has changed from C:\winnt\help\common to C:\winnt\help\iishelp\common.
Web Services has a new Service tab, which Screen 5 shows. The Administration tab, which Microsoft introduced in IIS 3.0, is no longer present; the setting has moved to the Service tab. The Service tab also includes controls for HTTP compression, which compresses files on the server and sends the compressed files to a browser. This option only works with browsers that support HTTP compression, such as Microsoft Internet Explorer (IE) 5.0. When you select the Compress static files check box in the HTTP Compression section, Web Services automatically enables the other compression settings. The Temporary folder option lets you specify the name of the folder in which the software stores the compressed files. When the program receives a request for an HTML file, Web Services determines whether the browser supports HTTP compression. If the browser supports compression, Web Services checks the file to determine if its content is static or dynamic. If the file is a static file (e.g., an .htm file), the software checks the cache for the file and sends the compressed file to the browser. (When Web Services compresses a static file, it automatically adds the file to the cache.) If the file is a dynamic file or isn't in the cache, the program compresses the file and sends it to the browser.
Because compressed files transmit much faster than uncompressed files, the Web Services documentation suggests that you use care when you set the HTTP compression and when you specify the temporary folder. HTTP compression is helpful if users access your site from a slow-speed connection, such as a modem, or if your server's network bandwidth is already high. However, Web Services requires CPU cycles to compress the files. If your CPU utilization is already at 80 or 90 percent, your server probably can't support file compression because the process will add too many CPU cycles. Also, you must place the temporary folder for compressed files on an uncompressed NTFS drive. To make good performance decisions for HTTP compression, you must understand the makeup of your site, test the system with various settings (by using tools such as Microsoft's Web Capacity Analysis Tool—WCAT or WebCat—or Web Application Stress—WAS—tool), and document which settings perform best. You can select the Limited to option at the bottom of the Service tab to specify a limit to the amount of disk space that HTTP compression consumes.
The ASP Applications Settings inherit WWW Service Master Properties sheet entries. (You can configure Application Settings from the Directory tab of a server's Properties sheet, if you haven't already done so in the WWW Service Master Properties sheet.) To examine these settings, I used Microsoft Visual InterDev to create IIS5Test on the Web Services server, then opened the IIS5Test Properties sheet, which Screen 6 shows.
Web Services lets you configure three levels of application process isolation. The first level is Low (IIS Process). This option causes the Web application to execute in the IIS process space. The application process isolation is low; if anything goes wrong with the application, the application might take IIS down with it. However, this level is the highest-performance type of application because the Web application doesn't need any cross-process marshalling or special handling.
The second level is Medium (Pooled). This level is new in Web Services. All the applications with a Medium (Pooled) isolation setting run together in the same process space. Dllhost.exe (a new component that Web Services uses to host isolated applications) hosts this pool of applications. Theoretically, applications in a pool perform better than isolated applications, but not as well as applications that run in the IIS process. This theory makes sense, but I haven't had a chance to test it.
The third isolation level is High (Isolated). When you select the High (Isolated) level, a separate instance of dllhost.exe runs each isolated application. This level provides the best isolation but affects performance because of the separate process spaces that the software uses for each application.
The Web Services documentation recommends that you run mission-critical applications with a High (Isolated) setting and run other applications with a Medium (Pooled) setting. Before you buy into these suggestions, I recommend that you test and determine the reliability of each option. IIS 4.0 makes similar recommendations, but through testing and working with many different ISPs and clients, I discovered that running an application with a high isolation setting causes numerous problems (e.g., the application runs slower and slower and eventually dies). The moral of the story: Test suggestions before you implement them.
I found one change on the Application Configuration sheet. (To view this sheet, click the Configuration button in the Application Settings section of either a server's Properties sheet, Directory tab or Master Properties sheet, Home Directory tab.) The Application Configuration sheet's App Mappings tab controls the mapping of various file extensions to the processor that handles the files. In IIS 4.0, the list of mappings contains excluded HTTP verbs for each entry. In Web Services, the mappings list contains HTTP verbs that apply to each entry.
Web Services also makes changes to ASP and the way ASP applications work. These changes add flexibility for developers. For example, new flow control features (server.execute and server.transfer) let developers access script in other pages without redirecting users to those pages.
One subtle ASP application change involves buffering. When you enable buffering, either IIS processes an entire ASP page before output or the page's script uses the Response.Flush method to force output while the page processes. Buffering can reduce the amount of processing that occurs for a page and improve an application's performance. (Buffering has some variation in how it works with different applications, so test buffering with your application to make sure you're getting the benefits.) In IIS 4.0, buffering was off by default. In Web Services, buffering is on by default. You can change this setting in the Application Configuration sheet's App Options tab.
Web Services also changes its method of processing ASP files that don't include server script. Earlier IIS versions automatically send all files with an .asp extension to the ASP script engine, which parses and processes all pages as if they contain script. Now, IIS quickly processes .asp files to determine whether they contain server script. If the files don't contain script, the files don't go to the script engine, and therefore process more quickly. The idea is to encourage developers to make all pages .asp files, whether they contain script or not. You can create a new .asp page without script and know that the page will process quickly, and you can add script to the page in the future without having to change any links to the page.
Many other changes affect IIS and applications that run on Win2K. If you upgrade an NT 4.0 server (with IIS 4.0 already installed) to Win2K, a number of Registry keys will disappear. What's Changed in the Web Services online documentation lists these keys and explains the most recent changes to the Registry keys.
Web Services still includes the HTML version of the ISM. You must start this application directly in the browser; you can't start the application from the Start menu in Web Services. If you haven't used the HTML version or you need more information, see Remote Administration in the Web Services online documentation.
You can now use the IIS metabase (which Microsoft introduced in IIS 4.0) to configure all IIS parameters. IIS moves both the ProcessorThreadMax and ErrorsToNTLog Registry entries to the metabase to facilitate this approach. To programmatically change these settings, you can use Microsoft Active Directory Service Interfaces (ADSI) and most languages (e.g., Visual Basic—VB, Visual C++VC++, VBScript), or you can use the ISM or other management tools. You can also use the IIS Administration Script Utility (Adsutil) to make these changes from the command prompt or a batch file. IIS provides two versions of Adsutil: Adsutil.vbs runs with VBScript, and adsutil.exe is an executable. Both versions take the same parameters. For more information about these options and other scripts, see Administration Scripts in the Web Services online documentation.
As I mentioned earlier, Win2K replaces MTS with COM+. I'd heard that Web Services and COM+ weren't as tightly integrated as IIS 4.0 and MTS. Out of curiosity, I changed IIS5Test to a high isolation setting. Then, I opened Component Services and browsed around. When you select the High (Isolated) level for a Web application, IIS creates a new COM+ application. The highlighted folder, which Screen 7 shows, is the COM+ Applications' IIS5Test folder. Screen 7 also shows the entry for the IIS Web Application Manager (IISWAM—which Microsoft introduced in IIS 4.0). For in-process applications, you can see that COM+ hosts Web Services like MTS hosts IIS 4.0. (For more information about in-process and out-of-process applications, see "Solving IIS Application Problems," January 2000.) The folders that relate to IIS resemble the folders that MTS creates with IIS 4.0: The IIS In-Process Applications folder represents a COM+ application for all IIS in-process applications, and the IIS Out-Of-Process Pooled Applications folder represents the COM+ application for pooled applications. These folders show that Web Services executes its applications under COM+ like IIS 4.0 does under MTS.
Ups and Downs
Web Services is full of new features for both administrators and developers. Although the new IIS often feels like good old IIS 4.0, you might need to search a bit to find a particular feature or option. Web Services appears to be faster and more reliable than any version of IIS that I've seen. Remember to test your applications before you make major configuration changes to IIS, even when the IIS documentation or other sources suggest certain settings.
The new IIS updates its ASP engine, and developers will find many new features for ASP and VBScript. I expect to see these features worked into applications soon. The new tools will certainly be good for the application development process. The downside is that many of these new features work only with Web Services. If applications depend on these features, the applications will be limited to Web Services servers.