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
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:
If IIS was installed correctly, your default Web browser
should open with the “Welcome to Windows 2000 Internet
Services” page and the online documentation.
Reasons to Like IIS 5.0 Now
- Quick uptime with Wizards
- Truly operable TCP/IP filtering
- Processor utilization details
- Improved process isolation
- Control over out-of-process task
- http and application file compression
- New and improved Active Server Pages
- Distributed authoring and versioning
- A new method for exchanging passwords
- 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.
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.
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.
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.
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
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
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
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
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.
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
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
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
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
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
|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.
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
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.