In-Depth

Web Wizardry: Putting the Internet to Work on Windows 2000

Hunting for that first compelling reason to install Windows 2000 now? Consider putting IIS 5.0 to work increasing your Web site’s security and performance.

It’s easy to overlook IIS 5.0 among the many new features included with Windows 2000 Server. At a glance, you may not even notice that it’s been updated. But for those of us who work with the Internet (read: everyone), it’s important to understand how the new features within Internet Information Server will affect your business.

If your company or client is like most, it’s looking for ways to improve the security, performance, and functionality of its Web site. Internet Information Server 5.0 offers companies a number of benefits, whether you’re installing it for a small intranet, a big corporation, or a large ISP. Security features have been greatly enhanced, performance configuration options improved, and much more. These improvements make upgrading your Web servers to Windows 2000 Server worth the cost and effort. I’ll quickly explain the install process for IIS 5.0, and then delve into some of the biggest of the new benefits this buried treasure in Windows 2000 offers.

Up and Running

If you didn’t choose to install the optional Internet Information Services (IIS) component when you installed Windows 2000 Server, it’s not too late. Open the Control Panel and launch the Add/Remove Programs applet. Click on Add/Remove Windows Components and select the Internet Information Service (IIS) checkbox. It’s a good idea to click the Details… button at this point and de-select any components you don’t immediately need. Installing only essential components minimizes your security risks and saves disk space—and it’s easy to add components later if you change your mind. Most people should deselect FrontPage 2000 Server Extensions, NNTP Service, Internet Services Manager (HTML), SMTP Service, and Visual Interdev RAD Remote Deployment Support—if you’re not sure you need them, you probably don’t. Once you’re happy with your selections, click Next until the installation is complete. You don’t need to reboot.

Once you’ve installed IIS, point a Web browser at your local system to make sure the installation was successful. You can do this quickly by choosing Run from the Start menu and typing:

http://localhost

If IIS was installed correctly, your default Web browser should open with the “Welcome to Windows 2000 Internet Services” page and the online documentation.

Web Administration

10 Reasons to Like IIS 5.0 Now
  1. Quick uptime with Wizards
  2. Truly operable TCP/IP filtering
  3. Processor utilization details
  4. Improved process isolation
  5. Control over out-of-process task CPU consumption
  6. http and application file compression
  7. New and improved Active Server Pages
  8. Distributed authoring and versioning control
  9. A new method for exchanging passwords
  10. FTP transfer restart

The Internet Services Manager, available within the Administrative Tools folder on your Start menu, is the primary tool you’ll use to administer your Web server. It’s almost identical to the Microsoft Management Console (MMC) interface provided with IIS 4.0; if you have previous experience, you’ll be right at home. An HTML version of the Internet Services Manager is also available and allows you to administer your server from a remote system with Internet Explorer. Unfortunately, the HTML interface is clumsy and a potential security weakness—use it only if you must administer your Web server through a firewall. A better option is to configure Terminal Services in Remote Administration mode and use that to administer remote Web servers.

Permissions Wizard

If there’s a single prominent theme within Win2K, perhaps it’s the use of Wizards. The Wizards within IIS make common administrative tasks simple for beginners, thereby accelerating the learning curve. Instead of presenting you with a complex dialog box, Win2K presents options individually with intelligent defaults and thorough explanations. You don’t need to do anything special to make use of the Wizards within IIS; if there’s a Wizard available for a particular task, it appears by default.

The Permissions Wizard, shown in Figure 1, will make it much simpler to configure permissions within both IIS and NTFS. IIS 4.0 administrators had to manually configure NTFS file and directory permissions to make their Web sites secure, and any mistake could render the site inoperable or insecure. To launch the Permissions Wizard, right-click on the Web site, scroll down to All Tasks, and select the Permissions Wizard.

Figure 1. No more manual NTFS file and directory permissions! The Permissions Wizard makes configuring permissions much easier—within both IIS and NTFS.

Traffic Filtering

The Internet is a dangerous place to put your server—security must be your primary concern. All the security features from IIS 4.0 are still part of IIS 5.0: SSL, NTFS file permissions, basic authentication, source IP address/domain name restrictions, and restricted script execution access. Windows NT/NTLM authentication still exists, but it's now called Integrated Windows authentication. Several new features have been added.

IIS, Then and Now

In 1996, IIS 1.0 was released for use with Windows NT 3.51 and included a bare-bones implementation of http, FTP, and Gopher services. These services were enough to turn an NT server into a Web server, but the feature set and performance couldn’t compete with Unix-based products that had existed for several generations.

When Microsoft introduced Windows NT 4.0, the product shipped with IIS 2.0—a significantly more stable product. IIS 3.0 was released shortly thereafter and included support for Active Server Pages (ASP) but dropped support for Gopher. ASP quickly became the scripting language of choice among Web developers, helping to make IIS popular. IIS 4.0 and the Option Pack, which were also released for use with NT 4.0, has allowed NT to become the second most popular Web server platform on the Internet today. According to the Netcraft Web Server Survey (www.netcraft.com/survey), IIS follows Apache, with about 22 percent of the market.

TCP/IP filtering is still available within the Network Control Panel applet, but now there are far more sophisticated filtering capabilities available by installing the Routing and Remote Access Service.

This service has a great deal of functionality, but perhaps the most useful aspect for Web servers is the capability to filter traffic based on source IP network, destination IP, and TCP or UDP port number. By creating traffic filters, you can allow the entire Internet access to your Web site while ensuring nobody but those on your private network can access it with Terminal Services.

The new Routing and Remote Access Services deserve an article unto themselves, so I can't cover them in detail here. However, the online documentation is a great place to start. Figure 2 shows an example of how to use the Routing and Remote Access Service to filter traffic on a public Web server. As you can see, all traffic from the internal network (10.0.0.0) is allowed, but only packets using TCP ports 80 (http) and 443 (https) are permitted from the rest of the Internet.

Figure 2. TCP/IP filtering in IIS 5.0 allows you to filter incoming traffic based on port number, thus separating public and private (intranet) traffic. Here’s an example of how to configure the public interface.

Isolating the Problems

Process Accounting is a new feature added to IIS 5.0 to help systems administrators and developers isolate problems with their applications. It adds processor utilization information to the IIS logs—if you’re using the W3C Extended log format. This information can then be used to identify inefficient out-of-process CGIs and ISAPIs. It doesn’t log the processor time required to handle in-process ASP, HTML and image file transfers. If you don’t use out-of-process CGIs and ISAPIs (or don’t know what they are), you never need to worry about Process Accounting or Processor Throttling.

To enable logging of process accounting information, open the Web site properties and select the Web Site tab to view the log configuration. Make sure logging is enabled and the W3C Extended Log File Format selected. Click the Properties button to view the Extended Logging Properties. When you click the Extended Properties tab, you’ll see a list of fields that can be added to your IIS log files. At the bottom of the list you’ll see a branch labeled Process Accounting and a handful of fields that give information about how a CGI or ISAPI is using the processor. Select any or all of these, apply the changes, and the new fields will be added to your IIS log files. The list of available fields is shown in Figure 3. Note that recording log information can have a negative impact on performance, but if you choose only what you really need, the trade-off will be worth it.

Figure 3. The new Process Accounting feature can help you isolate problems with applications. You’ll want to be selective about which fields you log, since recording can hurt performance.

Mastering Multitasking

Windows NT has always supported multitasking. One of the challenges of multitasking is allowing all services and applications to get their share of processing time. NT 4.0’s built-in multitasking did a good job of dividing processor time between threads. This works out well if everyone who shares a Web server writes perfect code. However, if just one of the Web sites has poorly written code, it can monopolize the processors and affect the performance of the other Web sites. In IIS 4.0 environments, this is a very real scenario.

IIS 5.0 contains a partial solution to this problem—Processor Throttling. This allows a systems administrator to restrict the CPU time that out-of-process tasks on a single Web site consume on a Web server. Processor Throttling affects ISAPI filters and CGIs, but it won’t affect the processor time that HTML, image files, and in-process ASPs receive. The Inetinfo process handles all of these standard tasks, even for multiple Web sites. So processor throttling can identify or stop a runaway application from bogging down your Web server, but it can’t control in-process ASP code.

To enable processor throttling, open the properties for the Web site. Select the Performance tab, check the Enable process throttling checkbox, and fill in a maximum CPU utilization percentage. Throttling will take effect if CPU use exceeds the specified threshold for a 24-hour period. Therefore, you won’t see anything for at least a day.

If you don’t select the Enforce limits option, IIS will operate as normal and add an event to the Event Log if a single Web site exceeds its processor utilization threshold. This capability, along with Process Accounting, is useful for auditing purposes and troubleshooting—if you’re concerned that one of your Web sites is using too much processor time, the Event Log will identify the culprit.

If you select Enforce limits, you enable IIS to take drastic measures. If the out-of-process applications exceed 150 percent of the processor time you’ve allocated, the out-of-process tasks will be placed at a very low priority—idle levels. This will stop the application from affecting the performance of other applications on the Web server, while still allowing it to execute during quiet periods. If the CGIs exceed 200 percent of the specified threshold, IIS will completely deny them further processing time. Therefore, enabling limits should be used only if you’re having serious problems—it will make your busiest sites fail at the most critical times. It’s better to deselect Enforce limits and use the Event Log to isolate and fix the problems than to starve critical Web sites of CPU time.

Modifying these settings within the MMC interface is sufficient for the majority of troubleshooting that you’ll need to do. If you want more control, edit the Metabase—IIS’ version of the registry. Describing the Metabase in any detail is outside the scope of this article, but you can find more information within the on-line documentation provided with IIS 5.0.

Moving Right Along

Bandwidth is a limited commodity on the Internet, so it makes sense to make every effort to reduce the amount of bandwidth that network communications requires. http compression is a simple, logical extension to standard http data transfers that compresses a file before transferring it across the network.

http compression makes use of existing http standards. During any http transfer, the Web browser sends the Web server a list of encoding methods that it can accept, using a message such as, “Accept-Encoding: gzip, deflate.” The Web server can then choose to send the response in a non-encoded format, or it can respond using one of the specified methods of encoding. IIS 5.0 supports compression using the gzip method of encoding. At the time of this writing, only IE 5.0 can successfully negotiate http compression with IIS 5.0. It should work with Netscape’s browser by the time you read this.

IIS doesn’t use http compression by default. If you choose to enable it, you’ll do so for all Web sites on a Web server. To edit http compression settings, open the IIS snap-in, right-click on your computer name, and choose Properties. Click the Edit… button to edit the Master Properties for the Web site. Select the Service tab, and you’ll see the dialog box shown in Figure 4.

Figure 4. The new http compression feature compresses a file before sending it across the network, but sender and receiver must be running IE 5.0. Set http compression in the IIS snap-in, as shown here.

At a minimum, I suggest enabling Compress static files. This will compress all files of type text/html. Static files don’t need to be compressed every time they’re accessed, because they don’t change frequently. So IIS caches the compressed version of the files to a local directory that you specify. If you have a lot of HTML content, it’s a good idea to limit the maximum temporary folder size so that the cache doesn’t fill up your partition.

You also have the option of compressing application files, such as the results of an ASP page. This isn’t as efficient as caching static files, because the results of the page can be different every time the page is executed. Therefore, IIS must recompress ASP content every time a client accesses it. This increases the load on the Web server processor. If bandwidth is the bottleneck on your network and your Web server is using its processors below 30 percent at peak time, you would benefit by enabling Compress application files. Otherwise, leave it disabled.

Isolating Processes

Whether you’re a Web developer or a systems administrator, you’ll appreciate the improved process isolation capabilities included with IIS 5.0. In short, the improvements allow application-intensive Web sites to be faster and more stable.

In IIS, an application is considered a group of files within a directory tree. These files can include ISAPI filters, ASP files, and CGI scripts—as well as the COM objects that they reference. In IIS 4.0, you have the option of running a directory either in-process (now called “low application protection”) or out-of-process (”high application protection”). Applications run faster in-process, but if they fail, they can cause the entire Web server to crash. IIS 5.0 adds a third option, now the default—you can run an application in a pooled process. All applications designated as pooled (labeled “medium application protection”) run within the same process. If one of them fails, they can affect the other pooled applications, but not the core IIS services.

An Updated ASP

As I mentioned earlier, Active Server Pages (ASP) has been one of the most significant factors in the success of IIS. ASP is a very efficient way to create scripts that execute on an IIS server. It’s tightly integrated with IIS itself, so performance tends to be much better than with traditional CGI scripts.

IIS 5.0 boasts an updated version of the ASP script engine, giving developers additional functionality.

For the first time in IIS 5.0, plain HTML files can be processed as ASP files with minimal impact on performance. This allows you to name all files, whether HTML or ASP, with an .ASP extension—without wasting too many processor cycles.

XML (Extensible Markup Language) support is one of the most useful new features within IIS 5.0’s ASP engine. XML provides a standard way to transfer unformatted data using http. Though similar in structure to HTML, it provides very different functionality. It allows a client to query a server for data such as a database record, a weather report, or a stock quote. Unlike with HTML, the client is free to do whatever it wants with the XML data. Style sheets, known as XSL (Extensible Style Language) and CSS (Cascading Style Sheet), can be used to format the data. Microsoft’s MSDN Web site has much more detailed information on XML; see “Additional Information” for a suggested reading list.

Systems administrators and developers won’t need to spend as much (or any) time tweaking thread settings within IIS 5.0. This was a very common—and time-consuming—task for administrators of ASP-intensive IIS 4.0 sites. The newest ASP processor can now dynamically allocate and de-allocate threads depending on the server load. This won’t affect the performance of sites that aren’t busy, but the Web sites that need help the most will benefit.

Another benefit is that ASP scripts can now be encoded. One of the disadvantages of scripting is that anyone can read the script—making plagiarism and reverse engineering a bit too easy. Both client-side and server-side ASP scripts can now be encoded, similar to the way Java applets are encoded. This will stop a user from using the “View Source” option on the browser to read your client-side scripts—but it doesn’t make it impossible. A debug utility can still be used to view the source code, minus any comments and formatting.

Another handful of other new features will only affect developers. I won’t detail those here, but you can find more information within the help files provided with IIS 5.0.

Web Distributed Authoring and Versioning

Managing HTML content can be quite a challenge. Applications such as FrontPage and Visual Interdev allow you to easily edit the content on a Web site, but wouldn’t it be nice if you could manage Web content with Windows Explorer or Internet Explorer? WebDAV (Web Distributed Authoring and Versioning) allows you to do just that, and it works with Microsoft Office 2000 applications too.

To allow clients to connect your Web site as a WebDAV location, just add a virtual directory and grant whichever rights you want the users to have. For example, if you want to users to be able to view and update files within a virtual directory, grant Read, Write, and Directory Browsing access.
To connect to a Web server with WebDAV configured, open Windows Explorer and choose Map Network Drive from the Tools menu. Click on Create a shortcut to a Web folder or FTP site. You’ll see the dialog box in Figure 5.

Figure 5. Web Distributed Authoring and Versioning allows you to manage Web content with Internet Explorer. To connect to a server with WebDAV configured, choose Map Network Drive from the Tools menu in Windows Explorer.

Enter the URL of the WebDAV location and answer the remaining questions posed by the Wizard. You’ll now be able to drop and drag files to your WebDAV location just like any other folder in Explorer!

Digest Windows Authentication

The new method of exchanging passwords, Digest Windows authentication, is more secure than basic authentication and more flexible than Integrated Windows authentication. When this method of authentication is used, a supported browser creates a one-way hash of the user’s password and sends the hash across the network. The server verifies the user by performing the same hash on the password and comparing the result to the value offered by the user. Digest Windows authentication works through proxy servers and firewalls, unlike Integrated Windows Authentication.

This method is more secure than basic authentication. Basic authentication doesn’t transmit the user’s password in clear text—it encodes it. Unfortunately, this encoding is easily reversible. If a malicious hacker can sniff a network connection between a user and a Web site using basic authentication, he or she can easily decode the user’s password. Digest Windows authentication is superior to this. If a malicious hacker sniffs the packets containing a password exchange using Digest Windows authentication, it’s practically impossible to reverse the hashing procedure.

SmartCard Security

Fortezza is a government standard that adds additional methods of encryption and authentication to IIS 5.0. It relies on a physical card called a SmartCard to carry certificate information, and is therefore more secure than technologies that don’t require a physical device.

If you don’t already know what Fortezza is, you can dismiss the technology. Private industry, now the vast majority of the Internet, will continue to rely on SSL client- and server-side certificates. However, it may be a requirement for organizations that are bound by government security policies. If you fall into that category, you’ll discover that Microsoft hasn’t put much effort into Fortezza—the only interface provided to configure it is a command line utility called “fortutil.”

FTP Restart

IIS 5.0 finally adds a feature common to most modern FTP clients and servers: FTP Restart. If an FTP transfer is interrupted, the client will start the download at the place where it left off. This can significantly reduce your frustration level when you’re downloading massive service packs or the latest beta from Microsoft.

Driven To Upgrade

IIS 5.0 would be a significant update even if it hadn’t been bundled with Windows 2000. If you manage a single Web server for your company, the improvements in performance and stability will drive you to upgrade soon. If you operate a Web hosting service, your customers will demand IIS 5.0 because of the improved security and application development features. Nobody will use all of the new features I’ve outlined here, but everyone will benefit in some way.

This article is based on Release Candidate 2 of Windows 2000 Server. Special thanks to Jason Smith and James Marcus.

comments powered by Disqus

Redmond Tech Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.