Internet Information Services 5.0 Technical Overview

Operating System


This paper gives information technology professionals a technical overview of the new features provided by Internet Information Services 5.0, delivered with Microsoft Windows 2000. These features include reliability and performance improvements such as Reliable Restart, Application Protection, and support for clustering. The paper also includes an extensive look at security provisions, and introduces new security protocols supported by IIS 5.0, including Transport Layer Security and Digest Authentication. For those using the Internet to share information, Web Distributed Authoring and Versioning (WebDAV) is also introduced. Application developers will find descriptions of a number of improvements to Active Server Pages (ASP).

On This Page

Introduction Reliability and Performance Security Application Environment Conclusion Additional Resources


As the Internet becomes more woven into mainstream businesses, so grows the need to have Web services interwoven with mainstream business computing. To address that need, Microsoft® Windows® 2000 Server includes an updated version of Internet Information Services (IIS), called IIS 5.0. As shown in Figure 1, Internet Information Services runs as an enterprise service within Windows 2000. It uses other services provided by Windows 2000, such as security and the Active Directory™ directory service.

This version improves the Web server's reliability, performance, management, security, and application services. Many of these improvements result from the way IIS 5.0 incorporates new operating system features provided in Windows 2000.


Figure 1: Windows 2000 Server services

With IIS 4.0, Microsoft focused on security, administration, programmability, and support for Internet standards. IIS 5.0 builds on the features and capabilities needed to deliver Web sites required in an increasingly Internet-centric business environment. And it makes it even easier to use the technologies delivered in prior versions. In particular, IIS 5.0 features improvements in the following four major areas:

Reliability and performance. A number of features make IIS more reliable and better performing. To make it faster and easier to restart IIS, the reliable restart feature of IIS 5.0 allows an administrator to restart Web services without rebooting the computer. To improve reliability, Application Protection provides the ability to run applications in a pool, separate from the Web services. The new CPU Throttling and Socket Pooling features in IIS 5.0 can also improve reliability. For application developers, Web site performance can be improved through new features such as scriptless Microsoft Active Server Pages (ASP) processing, ASP self-tuning, and performance-enhanced ASP objects.

Management. IIS 5.0 is easier to install and maintain. A number of features support this increased ease-of-maintenance, including a simplified installation process, new security task wizards, the ability to account for time used by processes, and more flexible remote administration.

Security. IIS 5.0 adds support for important industry-standard security protocols, including Digest Authentication, Server Gated Cryptography, Kerberos v5 authentication protocol, Transport Layer Security, and Fortezza. In addition, three new task wizards make it easier for administrators to manage a site's security settings.

Application environment. Developers will find that IIS 5.0 expands the Web server's application development environment by building on new technologies included in Windows 2000 Server. These include Active Directory and the expanded Component Object Model (COM+). In addition, enhancements to IIS Active Server Pages, such as scriptless ASP processing, as well as improved flow control and error handling, let developers write more efficient Web-centric applications.

This paper provides a technical overview of the key features and capabilities in IIS 5.0 to allow information technology and business professionals to assess the ways IIS 5.0 can fit into their business computing environments.

Reliability and Performance

IIS 5.0 performs better and is more reliable for a number of reasons. Internally, the speed of the IIS 5.0 engine has been increased through coding refinements. The new Reliable Restart feature lets system administrators restart the server more quickly. Beyond these inherent capabilities, this version introduces features you can use to improve the speed and reliability of Web sites.

One of the more significant reliability improvements in IIS 5.0 is the addition of application protection through support for pooled out-of-process applications. Generally, applications are faster but less reliable running in-process. However, it is quicker to run pooled out-of-process than isolated out-of-process applications. IIS 4.0 supported only isolated out-of-process applications.

To better control resource consumption, new throttling features (based on the new Job Object feature of Windows 2000) make it easier for administrators to allocate the amount of CPU bandwidth available to processes, as well as the amount of network bandwidth available to sites. In addition, the new Socket Pooling feature lets multiple sites that share a port also share a set of sockets. With the Windows 2000 Advanced Server, you can further increase your site's reliability by using clustering and replication features.

Application Protection

The Windows-based operating systems run services and applications in memory areas called processes. In IIS 5.0, Application Protection refers to the operating system process in which applications are run. In earlier versions of IIS, all Internet Server API (ISAPI) applications (including ASP technology) shared the resources and memory of the server process. Although this provided fast performance, unstable components could cause the server to crash, which made it more difficult to develop and debug new components. In addition, in-process components couldn't be unloaded unless the server was restarted—which meant that modifying existing components would affect all sites that shared the same server, whether they were directly affected by the upgrade or not.

As a first step toward addressing these issues, IIS 4.0 allowed applications to run either in the same process as Web services (Inetinfo.exe) or in a process separate from Web services (MTX.EXE ). In IIS 5.0, there is a third option: applications can be run in a pooled process separate from Web services. These three options provide varying levels of protection, each of which impacts performance. Greater isolation comes at the cost of slower performance.


Figure 2: Application protection

By default, Web services (Inetinfo.exe) will run in its own process, and other applications will be run in a single, pooled process (DLLHost.exe). If one application in the pool fails, it takes down all the applications in the pool, but the Web server still runs. To protect essential applications, you can set high priority applications to run as isolated processes (using another instance of DLLHost.exe).

As for performance, applications that are run in the Web services process (inetinfo.exe) run faster, but with a greater risk that a misbehaving application can make the Web services become unavailable. The recommended configuration is to run inetinfo.exe in its own process, run mission-critical applications in their own processes, and run remaining applications in a shared, pooled process, as shown in Figure 2, above. (Note: Because of the impact on performance, you shouldn't run more than 10 isolated applications.)

If you decide to run your application as a separate process, or with other applications in a single pooled process, you will need to select High (Isolated) or Medium (Pooled) from the Application Protection drop-down list on the Home Directory or Virtual Directory property sheet.

Note: Application protection can only be set at an application's starting-point directory. You can set process options for components in the Component Services administration tool.

Reliable IIS Restart

In the event of a system failure, it's clearly important to be able to get IIS back up and running as quickly as possible. In the past rebooting was an acceptable, although not optimal, way to restart IIS. To reliably restart IIS, an administrator needed to start up four separate services after every stoppage, and was required to have specialized knowledge, such as the syntax of the Net command. To avoid this, Windows 2000 includes IIS Reliable Restart, which is a faster, easier, more flexible one-step restart process.

The administrator can restart IIS by right-clicking an item in the Microsoft Management Console (MMC) or by using a command-line application. For greater flexibility, the command-line application can also be executed by other Microsoft and third-party tools (such as HTTP-Mon and the Windows 2000 Task Scheduler). IIS will use the Windows 2000 Service Control Manager's functionality to automatically restart IIS Services if the INETINFO process terminates unexpectedly.

Socket Pooling

Another area in which IIS 5.0 addresses performance is by adding the ability to optimize access to your Web site. A socket is an identifier for a particular node on a network. The socket consists of a node address and a port number, which identifies the service. For example, port 80 on an Internet node represents a Web server.

In IIS4, you could bind different Web sites to different IP addresses. Sites did not share sockets, but each site on a unique IP address had several sockets. These sockets are created when the site starts, and they consume significant non-paged memory (RAM). This memory consumption limits the number of sites bound to IP addresses that can be created on a single machine.

For IIS 5.0, this process has been modified so that sites bound to different IP addresses, but sharing the same port number, share the same set of sockets. The end result is that more sites can be bound to an IP address on the same machine than in IIS 4.0. In IIS 5.0, these shared sockets are used flexibly among all of the started sites, thus reducing resource consumption.

To decrease memory use and increase performance, socket pooling has been enabled by default for all sites using the same port but having different IP addresses. In general, this behavior should not be modified; however, you may want to disable socket pooling on mission-critical sites if they share their port with other less critical sites. If changed, the change should be made at the site level only so that other sites can continue to take advantage of the socket-pooling feature.

Multisite Hosting

Windows 2000 Server supports the ability to host multiple Web sites on a single server. This can save the time and money required within a company that wants to host different sites for different departments, or for an ISP hosting multiple sites for different customers.

The key to hosting multiple sites on a single server is the ability to distinguish between them. This can be done in several ways, each using the Web site's identification. Each Web site has a unique, three-part identity it uses to receive and to respond to requests: a port number, an Internet Protocol (IP) address, and a host header name. With IIS 5.0, companies can host multiple Web sites on a single server using three techniques: by assigning different ports, different IP addresses, or different host header names.

  • Port numbers. By using appended port numbers, you would only need one IP address to host many sites. In order for clients to reach your site, they would need to append a port number at the end of the static IP address (except for the default Web site, which uses port 80). So, for example, if your main site address is, you can create additional sites by using an appended port number, such as: There is a drawback to this approach: using this method of hosting multiple sites requires clients to type in the actual numerical IP address, DNS name, or machine name, followed by a port number.

  • Multiple IP addresses. As an alternative to multiple port numbers, you can host multiple IP addresses on a single computer. You can do this by binding multiple IP addresses to a single network card, or by adding an additional network card for each IP address. To use multiple IP addresses, you must also add the host name and its corresponding IP address to your name resolution system if you plan on reaching the sites via DNS names. IIS will accept incoming requests that have only the IP address. The only time you need to use a fully qualified domain name is when you use host headers for your unique ID. Then clients need only type the text name in a browser to reach your Web site.

    Note: If you are using this method of hosting multiple sites on the Internet, you will also need to register the text names with InterNIC.

  • Host header names. You can use different host header names with a single static IP address to host multiple sites. With support for host headers, an organization can host multiple Web sites on a single computer running Microsoft Windows 2000 Server with only one IP address and using only one port (such as, This lets ISPs and corporate intranets host multiple Web sites on a single server while offering separate user domains for each site. As in the previous method, you need to add the host names to your name resolution system. The difference is that once a request reaches the computer, IIS 5.0 uses the host name passed in the HTTP header to determine which site a client is requesting. If you use this method of hosting multiple sites on the Internet, you also need to register the DNS names with InterNIC.

    Note: You cannot use host headers when using Secure Sockets Layer (SSL) because HTTP requests using SSL are encrypted. Host headers are part of the encrypted request and cannot be interpreted and routed to the correct site. Also, be aware that older browsers are unable to pass host header names back to IIS. Microsoft® Internet Explorer 3.0, Netscape Navigator 2.0, and later versions of both browsers support the use of host header names; earlier versions of the two browsers do not. Visitors using older browsers will reach the default Web site for the IP address and will need additional support to reach the correct site.


One way to improve reliability and availability of Web sites is to link more than one computer together. This allows a couple things. First, a second computer can act as a backup machine ready to pick up the load should the other computer fail. Second, linked computers can also share a workload. Linking computers together to do these tasks is called clustering.

Available in Microsoft® Windows® 2000 Advanced Server, clustering allows multiple servers to be connected through clustering software so that they appear as one computer to users of the Web site. This connection allows them to use features that are not available with stand-alone server nodes, such as failover (picking up the work for a failed server) and load balancing (spreading the load among more than one server). Using server clusters increase a site's fault tolerance because if one server node stops working, another server node can immediately pick up the request load with minimal disruption to users. Server clusters can also share clustered disks containing important information such as a database.

Load balancing allows two or more servers to support larger amounts of activity by distributing the request load between them so that no one server node is overloaded or underutilized.

Windows Cluster Service provides two clustering technologies that can be used with IIS: Network Load Balancing clusters and server clusters. Network Load Balancing clusters provide high scalability and availability of up to 32 servers. Server clusters provide high availability through failover clustering of two connected servers. Depending on your needs and available resources, you can set up IIS in a multiple-node Network Load Balancing cluster (for high availability and scalability) or a two-node server cluster (for high availability only).

Server clusters provide static load balancing by the assignment of Web or FTP sites to a specific preferred server node, either manually or programmatically. Network Load Balancing clusters provide load balancing by distributing client connections among multiple server nodes. Typically, clusters are configured for both load balancing and fault tolerance.


Figure 3: Clustered services

Clustering increases reliability by providing the ability to transfer processes from one server to another in the case of a failure, and to balance the load between servers. The diagram above shows a basic server cluster configuration. Each server node has a local disk that can contain information specific to the node. Both nodes share resources on a hard disk, although only one node at a time can access resources on the disk. The nodes can be configured to use a private interconnect dedicated to cluster communication, or all network communication (including client and internal cluster communication) can take place on the same network connection. This configuration (minus the private interconnect) is necessary for all of the replication and clustering features available in IIS when deployed in a server cluster. The cluster structure makes load balancing and failover possible.


When using clustered servers, you might want to copy the contents of one server onto another computer. Replication involves copying content and configuration settings from one server to other servers so that all servers can offer the same resources to users. You need to replicate configuration settings for all clusters, whether they share content or not. You do not need to replicate content for clusters that share a data storage device such as a disk drive. Many clustering applications support replication of both content and configuration settings. IIS 5.0 provides a utility to replicate configuration settings from one computer to any number of other computers.

Internet Information Services (IIS) is designed to integrate with the Cluster service feature of Windows 2000 Advanced Server. IIS provides a command-line utility (Iissync.exe). This is for replicating the IIS metabase and other configuration settings (such as applications) from one server node to others. The utility is for replicating between nodes of a cluster. It is not supported when used to build separate servers. (The IIS metabase is a hierarchical structure for storing IIS configuration settings. It was introduced in IIS 4.0 to provide easier administration and require less disk space than the registry.) This utility provides a manual method for duplicating these settings.

For cases where you need to replicate both content and settings, you can use Content Deployment service (formerly known as the Content Replication System, or CRS) for replication across machines in a Web cluster. Content Deployment is a feature of Microsoft® Site Server.


Process Throttling

If you run multiple Web sites that primarily use HTML pages on one computer, or if you have other applications running on the same computer as your Web server, you can limit how much processor time a Web site's applications are permitted to use. This can help ensure that processor time is available to other Web sites or non-Web applications.

The new feature in IIS 5.0 that lets you control processor time is called Process Throttling. (It is also sometimes referred to as Process Limits, CPU Limits, or Job Object Limits.) Process Throttling lets server administrators limit the use of the CPU by out-of-process applications. An out-of-process application is one that is run in a separate memory space from the core IIS process—so that if an application stops responding or becomes unavailable, the crash doesn't stop the Web server from answering requests.

Per Web Site Bandwidth Throttling

If the network or Internet connection used by your Web server is also used by other services such as e-mail or news, you may want to limit the bandwidth used by your Web server in order to free up bandwidth for other services. A new feature in IIS 5.0 called Per Web Site Bandwidth Throttling lets administrators regulate the amount of server bandwidth each site uses by throttling the available bandwidth for the net card. This lets an ISP, for example, guarantee a predetermined amount of bandwidth to each site. As with Processor Throttling, this setting only affects static HTML files, not dynamic ASP files or any other kind of dynamic content.

Note: If you are using socket pooling (described above), which is enabled by default, throttling the bandwidth on one site also throttles all other sites sharing that port number.


While IIS 4.0 introduced a significant number of new technologies, a core design goal for IIS 5.0 was to make the Web server easier for managers to use. For example, some administrators found IIS 4.0 difficult to install. So, with IIS 5.0, the installation process is built right into the Windows 2000 Server setup. And, to make it easier to configure security settings, there are three new security wizards. In addition, this release includes improved command-line administration scripts as well as additional built-in management scripts.

Integrated Setup and Upgrade

The setup process for IIS 5.0 is integrated with the Windows 2000 Server setup, and IIS 5.0 installs by default as a networking service of Windows 2000 Server. A setup wizard helps you either install a new copy of IIS 5.0, or upgrade an older version.

IIS creates a default Web site and FTP site when you install Windows 2000 Server. You can add or remove IIS or select additional components by using the Add/Remove Programs application in Control Panel.

If you upgrade the Windows 95 or Windows 98 operating system to Windows 2000, IIS 5.0 is available with all versions of Windows 2000. IIS 5.0 will upgrade existing Web sites running on Windows 95, Windows 98, Windows NT Server 3.51, Windows NT Server 4.0, and Windows NT Workstation 4.0. Customers with any existing version of Windows NT Server 3.51 or 4.0 will automatically be upgraded to the new Web services in Windows 2000 Server and can take advantage of the new features and services of Windows 2000 Server and IIS.

Centralized Administration

IIS 5.0 is managed using the Internet Information Services Microsoft Management Console (MMC) snap-in. This administration tool for IIS 5.0 is integrated with other administrative functions of Windows 2000. (In previous releases this tool was called Internet Service Manager.) You can access the Internet Information Services snap-in by clicking Administrative Tools, clicking Computer Management, and then selecting it under Server Applications and Services. The browser-based administration tool, Internet Services Manager, is no longer available in the Administrative Tools program group, but it is still available to let you remotely administer IIS over an HTTP connection. In addition, you can use Terminal Services to remotely administer IIS by using the IIS snap-in.

Remote Administration

IIS 5.0 has Web-based administration tools that allow remote management of a server from almost any browser on any platform. Just as for local management, you have two interface options for remotely administering IIS 5.0: browser-based and through an MMC snap-in. (Using the MMC snap-in remotely requires Windows 2000 on the remote client. It also requires an opening in the Internet firewall.) The browser-based Internet Services Manager (HTMLA) lets you remotely administer certain IIS features over the Internet or through a proxy server. In addition to these two options, you can also use Terminal Services to access either the MMC or HTMLA administration tools. This approach requires that Terminal Services be installed on the server and the client used for remote access.

Delegated Administration

To help distribute the workload of administrative tasks, with IIS 5.0 administrators can set up administration accounts called Web Site Operators with limited administration privileges on Web sites. For example, an ISP that hosts sites for a number of different companies can assign delegates from each company as the Operators for each individual company's Web site. Operators can administer properties that affect only their respective sites. They do not have access to properties that affect IIS, the Windows server computer hosting IIS, or the network. This lets an IT or ISP administrator who hosts multiple Web sites on a single server delegate the day-to-day management of the Web site without giving up total administrative control.

Process Accounting

Process Accounting (sometimes referred to as CPU Usage Logging, CPU Accounting, or Job Object Accounting) is a new feature in IIS 5.0 that lets administrators monitor and log how Web sites use CPU resources on the server. ISPs can use this information to determine which sites are using disproportionately high CPU resources or that may have malfunctioning scripts or Common Gateway Interface (CGI) processes. IT managers can use this information to charge back the cost of hosting a Web site and/or application to the appropriate division within a company.

Process accounting is enabled on a per-server basis and records information on a per-Web site basis, but does not provide details on CPU usage of individual applications or CGI applications. The Process Accounting feature can only log information about out-of-process applications (those that do not share the same process as the Web server). Process accounting is available only for Web sites; it is not available for FTP sites.

Process accounting adds fields to the W3C Extended log file. These fields are recorded only when W3C Extended log file format is selected. The process accounting information is interspersed with other logging information in the file. Administrators can use the information gained from process accounting to determine if process throttling (described above) should be enabled on a Web site.

Improved Command-Line Administration Scripts

IIS 5.0 ships with scripts that can be executed from the command line to automate the management of common Web server tasks. Administration Scripts automate some of the most common administrative tasks. You can use them to create and control Web sites, applications, directories, and more. Administrators can also create custom scripts that automate the management of IIS.

Written in Microsoft Visual Basic® Scripting Edition (VBScript), the Administration Scripts are meant to be used with the Cscript.exe command-line scripting utility and work best if Cscript is registered for running .vbs files. You can run Administration Scripts by using the Microsoft VBScript files that are installed by default to the directory Inetpub\adminscripts. For increased performance, you can also use an executable version of adsutil.vbs (adsutil.exe, which is also installed by default to the directory Inetpub\adminscripts). This version accepts the same parameters as adsutil.vbs. Adsutil.exe is a sample that demonstrates how to manipulate the metabase using the Active Directory Service Interfaces (ADSI) in C/C++. (Adsutil.exe can read commands from a file, while adsutil.vbs cannot.)

Backing Up and Restoring IIS

The IIS MMC snap-in includes options that let you back up your IIS configuration so you can save the IIS 5.0 metabase settings to make it easy to return to a safe, known state.

Using this method lets you back up and restore your Web server configuration, but not your content files or those settings that remain in the registry. This method won't work if you reinstall IIS, and the resulting backup files cannot be used to restore an IIS configuration on other computers running Windows 2000. You can back up IIS by using the browser-based Internet Services Manager (HTML), but you must use the IIS snap-in to restore your configuration.

Custom Error Messages

When a user attempts to connect to a Web site and an HTTP error occurs, a generic message is sent back to the client browser with a brief description of what happened during the attempt to establish a connection. With IIS 5.0, you can send more informative error messages to clients that encounter an ASP or HTML error on your site. You can use the custom errors that IIS 5.0 provides or create your own.

All IIS 5.0 custom error messages display industry standard HTTP codes, which ensure consistency with HTTP 1.1 error messages. For example, if a user attempts to connect to a Web site that has reached its maximum connection capacity, an HTTP error will be returned in the form of an HTML page that contains the statement "Too many users."

You can use the Custom Errors property sheet in IIS to customize these generic HTTP errors:

Error Code

Error Message


Bad request


Logon failed


Logon failed due to server configuration


Unauthorized due to ACL on resource


Authorization failed by filter


Authorization failed by ISAPI/CGI application


Execute access forbidden


Read access forbidden


Write access forbidden


SSL required


SSL 128 required


IP address rejected


Client certificate required


Site access denied


Too many users


Invalid configuration


Password change


Mapper denied access


Client certificate revoked


Directory listing denied


Client Access Licenses exceeded


Client certificate untrusted or invalid


Client certificate has expired or is not yet valid


Not found


Site not found


Method not allowed


Not acceptable


Proxy authentication required


Precondition Failed


Request-URL too long


Internal server error


Application restarting


Server too busy


Requests for Global.asa not allowed


ASP error


Not implemented


Bad gateway

Support for FrontPage Server Extensions

Windows 2000 Server lets administrators use Microsoft FrontPage® Web authoring and management features to deploy and manage Web sites. With FrontPage Server Extensions, administrators can view and manage a Web site in a graphical interface. In addition, authors can create, edit, and post Web pages to IIS remotely. The Microsoft FrontPage MMC snap-in is a program that you use to administer the FrontPage Server Extensions and FrontPage-extended Web sites.

File Systems

Web Distributed Authoring and Versioning (WebDAV)

The Web is a great medium for publishing documents, but until now, it hasn't been easy for organizations to use the Internet to let users collaborate on documents. That's because while it is easy to read documents stored on a Web site, it has not been easy for users to make changes to those documents. Such an ability could, for example, make intranets much more useful.

To address this need, IIS 5.0 has full support for Web Distributed Authoring and Versioning (WebDAV). This is an extension of the HTTP 1.1 standard used for exposing any storage media, such as a file system, over an HTTP connection.

By setting up a WebDAV directory on your Web server, you can let users share documents over the Internet or intranet. WebDAV in IIS 5.0 takes advantage of the security and file access features provided by Windows 2000, so you can lock and unlock resources to let multiple people read a file, while only one person at a time can modify the file.

With the IIS 5.0 implementation of WebDAV, you can allow remote authors to move, search, edit, or delete files and directories—as well as their properties—on your server. WebDAV is configured using the Web server permission settings.

WebDAV addresses issues such as file access permissions, offline editing, file integrity, and conflict resolution when competing changes are made to a document. Because it is integrated into IIS 5.0, WebDAV lets you do the following:

  • Manipulate resources in a WebDAV publishing directory on your server. For example, with this feature, users with the correct permissions can copy and move files around in a WebDAV directory.

  • Modify properties associated with certain resources. For example, you can write to and retrieve a file's property information.

  • Lock and unlock resources so that multiple users can read a file concurrently, but only one person at a time can modify the file.

  • Search the content and properties of files in a WebDAV directory. Once connected to a WebDAV directory, you can quickly search the files on that directory for content as well as properties. For example, you can search for all files that contain the word table or for all files written by Fred.

Setting up a WebDAV publishing directory on your server is as straightforward as setting up a virtual directory through the IIS snap-in. Once you have set up your publishing directory, users with the correct permissions can publish documents to the server and manipulate files in the directory. (Before you can set up a WebDAV directory, you must install Windows 2000 Professional, Windows 2000 Server, or Windows 2000 Advanced Server.)


Figure 4: Sharing documents using WebDAV

From the client side, you can access a WebDAV publishing directory through one of the Microsoft products described in the following list or through any other client that supports the industry standard WebDAV protocol.

  • Windows 2000 connects to a WebDAV server through the Add Network Place wizard and displays the contents of a WebDAV directory as if it were part of the same file system on your local computer. Once connected, you can drag and drop files, retrieve and modify file properties, and do other file-system tasks.


    Figure 5: Users can set up a connection to a WebDAV directory using the Add Network Place wizard in Windows 2000.

  • Microsoft Internet Explorer 5 connects to a WebDAV directory and lets you do the same file system tasks as you can through Windows 2000.

  • Microsoft Office 2000 creates, publishes, edits, and saves documents directly into a WebDAV directory through any application in Office 2000.

WebDAV makes use of the security features offered by both Windows 2000 and IIS 5.0. These features include the IIS permissions specified in the IIS snap-in and the discretionary access control lists (DACLs) in the NT file system (NTFS).

Because clients with proper permissions can write to a WebDAV directory, it is vital that you can control who is accessing your directory at all times. To help control access, IIS 5.0 has reinforced integrated Windows authentication by building in support for the Kerberos version 5 authentication protocol. By selecting integrated Windows authentication, you can make sure that only clients with permission can access and write to the WebDAV directory on your intranet. In addition, IIS 5.0 introduces a new type of authentication called Digest Authentication. Created for Windows domain servers, this type of authentication offers tighter security for passwords and for transmitting information across the Internet. (For more information about authentication, see the "Security" section of this paper.)

Web Folders

Shortcuts to shared files created using WebDAV (described above) and stored on Web servers are known as Web Folders or HTTP Folders. The shortcuts are created automatically in My Network Places whenever you open resources on a WebDAV-compliant server, if you have read and write access to the server. You can also use the Add Network Place wizard to create shortcuts to Web servers and other computers.

Support for Web Folders lets users navigate to a server and view the content as if it were part of the same namespace as the local system. Users can drag and drop files, retrieve or modify file property information, and perform other file system-related tasks. Web Folders let users maintain a consistent look and feel between navigating the local file system, a networked drive, and an Internet Web site. However, when you view the contents of a Web folder, you see a list of files and folders and their associated Internet addresses.

Dfs As Filing System for IIS

IIS 5.0 makes use of the Windows 2000 distributed file system (Dfs). Dfs is a means for uniting files on different computers into a single name space. Dfs lets system administrators build a single, hierarchical view of multiple file servers and file server shares on the network. By doing this, Dfs lets you make it easier for users to access and manage files that are physically distributed across a network. With Dfs, you can make files that are distributed across multiple servers appear to users as if they reside in one place on the network. Users no longer need to know and specify the actual physical location of files in order to access them.

The distributed file system is always hosted on Windows NT Server 4.0 or Windows 2000 Server, either in file allocation table (FAT) or NTFS format. You can use Microsoft Dfs as the filing system for IIS 5.0 by selecting the root for the Web site as a Dfs root. Doing so lets you move resources within the Dfs tree without affecting any HTML links. (Windows Media Services content can also be stored in the Dfs tree.)

HTTP Compression

HTTP compression allows faster transmission of pages between the Web server and compression-enabled clients. This is useful in situations where bandwidth is limited. Depending on the content you're hosting, your storage space, and the connection speed of your typical Web site visitor, HTTP compression can provide faster transmission of pages between the Web server and compression-enabled browsers. If your server generates a large volume of dynamic content, consider whether the additional processing cost of compression is one that you can reasonably afford. If the percent Processor Time (accessed through the System Monitor) is already extremely high (80 percent or more), compression is not necessarily a good option.

File Transfer Protocol (FTP) and FTP Restart

The File Transfer Protocol (FTP) service, an industry standard protocol used to publish information to a Web server, is integrated into Windows 2000 Server. In IIS 5.0, the FTP Restart protocol is also supported by Windows 2000 Server. It provides a faster and smoother way to download information from the Internet because if an interruption occurs during data transfer from an FTP site, a download can continue where it left off without having to download the entire file over again.


Security features are an important area of improvement in IIS 5.0, which takes advantage of the Internet-standard security features that are fully integrated with Windows 2000.

This discussion of IIS 5.0 security is broken into three major sections. The first addresses Internet-standard security protocols supported by IIS 5.0. To help you visualize how the new protocols fit into the security infrastructure, this section also gives brief descriptions of existing protocols supported in prior versions of IIS. Of particular interest in IIS 5.0 is support for emerging standards including: Fortezza, Transport Layer Security, Digest Authentication, and the Kerberos v5 authentication protocol.

Security standards are used in conjunction with a multi-step process used to secure Web sites. To better explain how the new features improve the security of IIS 5.0, the second section of this discussion describes each new feature in the context of these security procedures.

The last section of this security discussion introduces the new task wizards in IIS 5.0 that make it easier for administrators to set up IIS 5.0 security.

Security Standards

Microsoft is committed to working with the Internet and computer communities to help structure and implement sound security standards. The security protocols supported in IIS 5.0 include:

  • Fortezza. Support for the U.S. government security standard called Fortezza is new in IIS 5.0. Fortezza satisfies the Defense Message System security architecture with a cryptographic mechanism that provides message confidentiality, integrity, authentication, non-repudiation, and access control to messages, components, and systems. These features are implemented both with server and browser software and with Personal Computer Memory Card International Association (PCMCIA) card hardware.

  • Secure Sockets Layer (SSL 3.0). SSL security protocols are used widely by Internet browsers and servers for authentication, message integrity, and confidentiality. You can configure your Web server's SSL security features to verify the integrity of your content, verify the identity of users, and encrypt network transmissions. SSL relies upon certificates, which are described below.

  • Transport Layer Security (TLS). TLS is based on SSL. It provides for cryptographic user authentication and provides a way for independent programmers to write TLS-enabled code that will then be able to exchange cryptographic information with another process without either programmer needing to be familiar with the other programmer's code. In addition, TLS is intended to provide a framework that can be used by new public key and bulk encryption methods as they emerge. TLS also focuses on improving performance by reducing network traffic and providing an optional session caching scheme that can reduce the number of connections that need to be established from scratch.

  • PKCS #7. This protocol describes the format of encrypted data such as digital signatures or digital envelopes that securely contain information. Both of these are involved in the certificate features of IIS.

  • PKCS #10. This protocol describes the format of requests for certificates that are submitted to certification authorities.

  • Basic Authentication. Basic Authentication is a part of the HTTP 1.0 specification. It sends passwords over networks in Base64 encoded format. The Basic Authentication method is a widely used, industry-standard method for collecting user name and password information. The advantage of Basic Authentication is that it is part of the HTTP specification, and is supported by most browsers. The disadvantage is that Web browsers using Basic Authentication transmit passwords in an unencrypted form. By monitoring communications on your network, someone could easily intercept and decipher these passwords by using publicly available tools. Therefore, Basic Authentication is not recommended unless you are confident that the connection between the user and your Web server is secure, such as a direct cable connection or a dedicated line.

  • Digest Authentication. A new feature of IIS 5.0, Digest Authentication offers the same features as Basic Authentication but involves a different method for transmitting the authentication credentials. The authentication credentials pass through a one-way process, often referred to as hashing. The result of this process is called a hash, or message digest, and the original text cannot be deciphered from the hash.

    The server generates additional information that is added to the password before hashing so no one can capture the password hash and use it to impersonate the true client. This a clear advantage over Basic Authentication, in which the password can be intercepted and used by an unauthorized person.

    Digest Authentication is structured to be usable across proxy servers and other firewall applications and is available to Web Distributed Authoring and Versioning (WebDAV). Because Digest authentication is a new HTTP 1.1 feature, not all browsers support it. If a non-compliant browser makes a request on a server that requires Digest Authentication, the server will reject the request and send the client an error message. Digest Authentication is supported only for domains with a Windows 2000 domain controller, and can only be used with Internet Explorer version 5 or later.

For more information about securing a domain controller, see the Microsoft Windows 2000 Server Resource Kit.

Security Mechanisms

The five major security mechanisms used in IIS 5.0 are:

  • Authentication, to verify user identities.

  • Certificates, to securely send and receive site identity information.

  • Access control, to protect access to your content.

  • Encryption, to prevent tampering with content.

  • Auditing, to monitor security-related activity on your site.


Authentication lets you confirm the identity of anyone requesting access to your Web sites. The types of authentication supported in IIS 5.0 include:

  • Anonymous Authentication. This method gives users access to the public areas of your Web or FTP site without prompting them for a user name or password. If Anonymous Authentication is enabled, IIS will always try to authenticate using it first, even if other methods are enabled. When a user attempts to connect to your public Web or FTP site, your Web server assigns the user to the Windows user account called IUSR_computername, where computername is the name of the server on which IIS is running.

    If you have multiple sites on your server, or if you have areas of your site that require different access privileges, you can create multiple anonymous accounts, one for each Web or FTP site, directory, or file. By giving these accounts differing access permissions, or by assigning these accounts to different Windows user groups, you can grant users anonymous access to different areas of your public Web and FTP content.

  • Basic FTP Authentication. To establish an FTP connection with your Web server by using Basic FTP Authentication, users must log on with a user name and password corresponding to a valid Windows user account. If the FTP server cannot verify a user's identity, the server returns an error message. FTP authentication is not very secure because the user transmits the password and user name across the network in an unencrypted form.

  • Anonymous FTP Authentication. You can configure your FTP server to allow anonymous access to FTP resources. If Anonymous FTP Authentication is enabled, IIS will always try to use it first, even if Basic Authentication is enabled. If you select Anonymous Authentication for a resource, all requests for that resource will be taken without prompting the user for a user name or password.

  • Integrated Windows authentication. Administrators can pass authentication credentials among connected computers running Windows. Users can securely authenticate themselves to a Windows 2000 Server Web site and will not have to undergo a separate authentication (logon) to use other resources. This is possible because of the integrated Windows authentication services.

    Formerly called NTLM or Windows NT Challenge/Response authentication, integrated Windows authentication is secure because the user name and password are not sent across the network. Instead, the user's browser proves its knowledge of the password through a cryptographic exchange with your Web server. One method of exchanging the information is using the Kerberos v5 authentication protocol.

    Kerberos v5 is a feature of the Windows 2000 Distributed Services architecture. Windows 2000 Server Web services are fully integrated with the Kerberos security infrastructure. Kerberos v5 provides fast, single logon to Windows 2000 Server, and replaces NTLM as the primary security protocol for access to resources within or across Windows 2000 domains. In order for Kerberos v5 authentication to be successful, both the client and server must have a trusted connection to a Key Distribution Center (KDC) and be Active Directory compatible.

    Integrated Windows authentication can use both the Kerberos v5 authentication protocol and its own challenge/response authentication protocol.

    Although integrated Windows authentication is secure, it does have two limitations. First, only Microsoft Internet Explorer version 2.0 or later (IE 5.0 or later for Kerberos), supports this authentication method. Second, integrated Windows authentication does not work over HTTP, or through any CERN based proxy Proxy connections. Therefore, integrated Windows authentication is best suited for an intranet environment, where both user and Web server computers are in the same domain, and where administrators can ensure that every user has Microsoft Internet Explorer version 2.0 or later.


To complete the authentication process, you need a mechanism for verifying user identities. Certificates are digital identification documents that allow both servers and clients to authenticate each other. They are required for the server and client's browser to set up an SSL connection over which encrypted information can be sent. Server certificates usually contain information about your company and the organization that issued the certificate. Client certificates usually contain identifying information about the user and the organization that issued the certificate.

The certificate-based SSL features in IIS consist of a server certificate, an optional client certificate, and various digital keys. You can create these certificates with Microsoft Certificate Services or obtain them from a mutually trusted, third-party organization called a certification authority (CA).

Certificate authentication. You can use your Web server's Secure Sockets Layer (SSL) security features for two types of authentication. You can use a server certificate to allow users to authenticate your Web site before they transmit personal information, such as a credit card number. Also, you can use client certificates to authenticate users requesting information on your Web site. SSL authenticates by checking the contents of an encrypted digital identification submitted by the user's Web browser during the logon process.

Client certificate mapping. You can associate, or map, client certificates to Windows user accounts on your Web server. After you create and enable a certificate map, each time a user logs on with a client certificate, your Web server automatically associates that user to the appropriate Windows user account. This way, you can automatically authenticate users who log on with client certificates, without requiring the use of either Basic, Digest, or integrated Windows authentication. You can either map a single client certificate to one Windows user account or many client certificates to one account. For example, if you had several different departments or businesses on your server, each with its own Web site, you could map all of the client certificates of each department or company to its own Web site. This way each site would provide access only to its own clients.

Certificate storage. IIS certificate storage is now integrated with the Windows CryptoAPI storage. The Windows Certificate Manager provides a single point of entry that lets administrators store, back up, and configure server certificates.

Access Control

After verifying the identity of a user, you'll want to control their access to resources on your server. IIS 5.0 uses two layers of access control: Web permissions and NTFS permissions. Web permissions apply to all HTTP clients and define what HTTP verbs can be used to access server resources. NTFS permissions define what level of access individual user accounts have to directories and files on the server.

For example, if a business decided to publish its catalog on your Web server, you would need to create a Windows user account for that business and then configure permissions for the specific Web site, directory, or file. The permissions would enable only the server administrator and the owner of the business to update the Web site's contents. The permissions would also allow public users to view the Web site, but they could not alter its contents.

To allow users to both access and modify Web content, IIS 5.0 implements the WebDAV standard (described above), which is an extension of the HTTP 1.1 protocol that facilitates file and directory manipulation over an HTTP connection. Through the use of WebDAV verbs, or commands, properties can be added to, and read from, files and directories. Files and directories can also be remotely created, deleted, moved, or copied. Additional access control can be configured through both Web server permissions and NTFS.


Once you've controlled access to information, you need to protect that information as it passes over the Internet. You can let users exchange private information, such as credit card numbers or phone numbers, with your server in a secure way by using encryption. Encryption scrambles the information before it is sent, and decryption unscrambles it after it is received. The foundation for this encryption in IIS is the SSL 3.0 protocol, which provides a secure way of establishing an encrypted communication link with users. SSL confirms the authenticity of your Web site and, optionally, the identity of users accessing restricted Web sites.

Certificates (discussed above) include encrypted keys used in establishing an SSL secure connection. A key is a unique value used to authenticate the server and the client in establishing an SSL connection. A public key and a private key form an SSL key pair. Your Web server uses the key pair to negotiate a secure connection with the user's Web browser to determine the level of encryption required for securing communications.

For this type of connection, both your Web server and the user's browser must be equipped with compatible encryption and decryption capabilities. During the exchange an encryption, or session, key is created. Both your server and the Web browser use the session key to encrypt and decrypt transmitted information. The session key's degree of encryption, or strength, is measured in bits. The greater the number of bits comprising the session key, the greater the level of encryption and security. Although these greater encryption key strengths offer greater security, they also require more server resources to implement. Your Web server's session key is typically 40 bits long, but can be 128 bits long depending upon the level of security you require (see the section "Server Gated Cryptography," below).

Server-Gated Cryptography (SGC) is an extension of SSL that allows financial institutions with export versions of IIS to use strong (128-bit) encryption. Although SGC capabilities are built into IIS 5.0, a special SGC certificate is required to use SGC.

You can configure your Web server to require a 128-bit minimum session-key strength, rather than the default 40-bit key strength, for all SSL secure communication sessions. If you set a minimum 128-bit key strength, however, users attempting to establish a secure communications channel with your server must use a browser capable of communicating with a 128-bit session key.


  • Due to export restrictions, the 128-bit key strength encryption feature is available only in the United States and Canada. For information about upgrading to 128-bit encryption capability, visit the Windows 2000 Server support Web site at

  • When you set security properties for a specific Web site, you automatically set the same security properties for directories and files belonging to that site, unless the security properties of those individual directories and files have been set previously.

  • Your Web server will prompt you for permission to reset the properties of individual directories and files when you attempt to set security properties for your Web site. If you choose to reset these properties, your previous security settings will be replaced by the new settings. The same condition applies when you set security properties for a directory containing subdirectories or files with previously set security properties.

  • Setting Require 128-bit encryption for Web site with a server certificate with keys of length less than 128 bits will disable access to that site.


The last step to ensuring security is to regularly monitor your site's usage. Administrators can use security auditing techniques to monitor a broad range of user and Web server security activity. Auditing consists of creating auditing policies for directory and file access or server events, and monitoring the security logs to detect any access attempts by unauthorized persons.

You can configure the security logs to record information about either directory and file access, or server events, or both. It is a good idea to routinely audit your server configuration to detect areas where resources may be susceptible to unauthorized access and tampering. You can use the integrated Windows utilities, or the logging features built into IIS 5.0, or use ASP applications to create your own auditing logs.

You can monitor access attempts, either successful or unsuccessful, at the directory or file level. This includes events such as reading the file, writing to the file, and browsing a directory. You can choose which events you want to audit for any file or directory. Your server's file system must be configured to NTFS to use these auditing features.

You can monitor server-wide events, such as logging on and off the Web server, changing Web server security policies, and shutting down the server computer. Events are audited for the entire computer, rather than certain directories or files. This level of auditing is set by using the Audit Policies in the Microsoft Management Console. You can also monitor attempts, either successful or unsuccessful, to access your Web or FTP sites, virtual directories, or files. This includes events such as reading the file or writing to the file. You can choose which events you want to audit for any site, virtual directory, or file. This level of auditing is set by using the IIS snap-in.

Security Wizards

To make it simpler to establish and maintain security settings, IIS 5.0 includes three new security task wizards:

  • Certificate Wizard simplifies certificate administration tasks, such as creating certificate requests and managing the certificate life cycle. Secure Sockets Layer (SSL) security is an increasingly common requirement for Web sites that provide e-commerce and access to sensitive business information. The new wizard makes it easy to set up SSL-enabled Web sites on Windows 2000 Server. In addition, this wizard makes it easier to establish and maintain SSL encryption and client certificate authentication.

    Obtaining, configuring, and renewing server certificates can now all be done through one interface in the Web Server Certificate Wizard. The wizard can detect whether a server certificate has already been installed and if it is about to expire. You can use the wizard to replace the server certificate with another one from a certification authority (CA), from an online CA, such as Microsoft Certificate Services, or from a file previously obtained in Key Manager. You can also reassign a certificate from one Web site to another Web site.

    Note: Online requests for server certificates can only be made to Enterprise Certificate Servers. The IIS Web Server Certificate Wizard will not recognize a stand-alone Certificate Server on the same machine. Use the offline certificate request to save the request to a file, and then process as an offline request. Online enrollment using a local Enterprise Certificate Server is not affected.

    If you are not using an online certification authority, you will need to save the request file generated by the Web Server Certificate Wizard to disk and send it to the CA. When the response is received, you can start the wizard and it will begin where it left off before. If you are replacing a certificate, IIS will continue to use the old certificate until the new request is completed.

  • Permission Wizard walks administrators through the tasks of setting up permissions and authenticated access on an IIS Web site, making it much easier to set up and manage a Web site that requires authenticated access to its content.

    The Permissions Wizard takes a scenario-driven approach in setting up Web and FTP permissions, NTFS access permissions, and authentication schemes. Rather than using a separate user interface to set each area, you select the configuration that most closely resembles your site's needs and the wizard sets all of the access permissions and authentication schemes for you. One of the great advantages of this is that the wizard will ensure that Web (or FTP) and NTFS permissions are properly coordinated and that the correct authentication scheme is used. All of the settings can still be changed in the IIS snap-in. The configurations are:

    • Public Web site. This is the most common configuration, in which the information on the site is intended for public consumption over the Internet. It uses anonymous authentication and allows users to view all files and access ASP applications on your Web server. It also gives administrators complete control over the site.

    • Secure Web site. This configuration is used for corporate extranets, which are intranets accessed over the Internet. Information on the site is intended for restricted consumption. It uses Basic, Digest, or integrated Windows authentication. It allows only authorized users to view all files and access ASP applications on your Web server. It also gives administrators complete control over the site.

  • Certificate Trust Lists (CTL) Wizard lets administrators configure CTLs. A CTL is a list of trusted certification authorities (CAs) for a particular directory. By configuring your CTL, you can allow certificates issued by one CA to be used but not from another CA. CTLs are especially useful for ISPs that have several Web sites on their server and who need to have a different list of approved CAs for each site. CTLs are available only at the Web site level and are not available for FTP sites.

Application Environment

IIS 5.0 adds performance enhancements to make it easier to develop Web-enabled applications. The Active Server Pages (ASP) technology within IIS, combined with the data access and component services within Windows 2000 Server, provides a well-rounded application environment.

With this release, enhanced flow control and error handling, Windows Script Components, and other improvements make ASP easier to use for script writers and Web application developers. In addition, features such as scriptless ASP, ASP self-tuning, and performance-enhanced objects, as well as improvements within the Windows 2000 operating system, can increase the speed of ASP applications.

What's New in ASP

ASP is a server-side scripting environment that you can use to create and run dynamic, interactive Web server applications. With ASP, you can combine HTML pages, script commands, and Component Object Model (COM) components to create interactive Web pages or Web-based applications that are easy to deploy and modify. There are a number of new ASP features in IIS 5.0, such as new flow control capabilities and error handling features that make it easier to write and control the behavior of Web applications. Other new features, such as scriptless ASP processing, improve the performance of ASP pages.

Flow Control Capabilities

New flow control capabilities let Web developers write more efficient ASP-based applications by letting them reduce the number of roundtrips required between a client and the server.

Using the Response.Redirect method to redirect a browser requires a roundtrip to the server, meaning that the server sends an HTTP response to the browser indicating the location of the new URL. The browser automatically leaves the server's request queue and sends a new HTTP request for this URL. The server then adds this request to the request queue along with other clients' requests that arrived in the meantime. For a busy Web site, roundtrips can waste bandwidth and reduce server performance—especially when the browser is redirected to a file located on the same sever.

The ASP Server object now has two new methods that you can use to control program flow: Server.Transfer and Server.Execute. As shown in Figure 6, you can use the Server.Transfer method to transfer from one ASP file to another file located on the same server, instead of the Response.Redirect method. With Server.Transfer you can directly transfer requests for ASP files without ever leaving the server request queue, thus eliminating costly roundtrips.

Figure 6: The Server.Transfer method can save round trips to the server when a URL is redirected to another ASP page on the same server.

Figure 6: The Server.Transfer method can save round trips to the server when a URL is redirected to another ASP page on the same server.

ASP also provides the Server.Execute method that you can use to transfer to a file, execute its content, and then return to the file that initiated the transfer. If you are familiar with VBScript, it will help you to think of Server.Execute as analogous to a procedure call, except that instead of executing a procedure, you are executing an entire ASP file.

Browser Capabilities Component

To make Web applications more responsive to a particular user's browser, ASP has a new feature for determining the exact capabilities of a browser. When a browser sends a cookie describing its capabilities (such a cookie can be installed by using a simple client-side script) developers can create an instance of the Browser Capabilities component that retrieves the browser's properties as returned by the cookie. You can use this feature to discover a browser's capabilities and adjust your application accordingly.

The Browser Capabilities component creates a BrowserType object that provides your scripts with a description of the capabilities of the client's Web browser. When a browser connects to the Web server, it automatically sends an HTTP User Agent header. This header is an ASCII string that identifies the browser and its version number. The BrowserType object compares the header to entries in the Browscap.ini file. If it finds a match, the BrowserType object assumes the properties of the browser listing that matched the User Agent header. If the object does not find a match for the header in the Browscap.ini file, it searches for the closest match using the * and ? wildcards. If a match can not be found using wildcards, the object will use the default browser settings if they have been specified in the Browscap.ini file. If the object does not find a match and default browser settings have not been specified in the Browscap.ini file, the object sets every property to the string UNKNOWN.

You can add properties or new browser definitions to this component simply by updating the Browscap.ini file.

Error Handling

ASP now has a new error-handling capability that can help you find errors in their Web applications. This feature lets you trap errors in a custom error message ASP file. You can use the new Server.GetLastError method to display useful information, such as an error description or the line number where the error occurred. You can use the ASPError object to obtain information about an error condition that has occurred in script in an ASP page. The ASPError object is returned by the Server.GetLastError method. The ASPError object exposes read-only properties.

Scriptless ASP

In prior versions, all ASP pages were processed as though they included script. This meant that even pages without script were still channeled through the ASP parser before being presented to the client, even though they didn't need server-side processing. Pages coded as static HTML were generally processed faster, as they did not require this trip to the server. If developers wanted to avoid an unneeded call to the ASP parser, they had to code scriptless pages as HTML, and only use the .asp extension on pages that included script. IIS 5.0 addresses this inefficiency by adding an initial step that examines an ASP page to see if it includes server-side scripting before sending it to the parser. If a page doesn't include script, it's served without the trip to the parser. Though HTML pages still process more quickly than ASP pages, with IIS 5.0, ASP pages that don't include scripting are served more quickly than they were in the past. And, you don't have to keep track of two different file types.

Performance-Enhanced Objects

To improve the speed of Web-based applications, IIS 5.0 ASP includes performance-enhanced versions of its popular installable components, which will scale reliably in a wide range of Web publishing environments. These components, which have been rewritten to improve their performance, are used to carry out commonly needed tasks, such as rotating advertisements (adrot.dll) and determining a browser's capabilities (browscap.dll).

ASP Self-Tuning

IIS will increase and decrease the number of threads whether ASP thread gating is enabled or not. When ASP thread gating is enabled, ASP will monitor the CPU and when it reaches a set threshold, ASP will start restricting the number of ASP threads that are allowed to execute.

In response to varying load conditions, IIS performs thread gating to dynamically control the number of concurrently executing threads. Thread gating is disabled by default. The default settings for the ASPThreadGateEnabled property, and the other thread gating properties, are designed to be appropriate for the majority of server configurations and traffic conditions. Changing these properties can lead to significant performance degradation.

The Web service setting for the ASPThreadGateEnabled property is applicable to all in-process and pooled out-of-process application nodes, at all levels. Metabase settings at the Web server level or lower will be ignored for in-process and pooled out-of-process applications. However, settings at the Web server level or lower will be used if that node is an isolated out-of-process application.

XML Integration

Just as HTML lets you describe the format of a Web document, Extensible Markup Language (XML) lets you semantically describe the complex structure of data or documents, which can then be shared across a variety of applications, clients, and servers. Using the Microsoft XML Parser, included with Internet Explorer version 4.0 or later, you can create server-side applications enabling your Web server to exchange XML-formatted data with Internet Explorer version 4.0 or later, or with other servers having XML parsing capabilities.

Windows Script Components

ASP supports the new Microsoft scripting technology, Windows Script Components. This technology lets developers turn business logic script procedures into reusable COM components for use in Web applications, as well as in other COM-compliant programs.

Windows Script Components provide an easy way to create COM components using scripting languages such as VBScript and other languages compatible with the ECMA 262 language specification (such as Microsoft JScript® 2.0 and JavaScript 1.1). You can use script components as COM components in applications such as IIS, Microsoft Windows Script Host (WSH), and any other application that can support COM components.

Server-Side Include with SRC Attribute

Server-side Includes let you include dynamic text, such as the current date, in Web documents. In IIS 5.0, you can now use the HTML SCRIPT element's SRC attribute to do server-side includes. When you use the SRC attribute to specify a virtual or relative path, and use the RUNAT=SERVER attribute to denote server-side execution, you can achieve the same functionality as the #Include directive.

Encoded ASP Scripts

Traditionally, Web developers have not been able to prevent others from viewing the logic behind their scripts. ASP now supports a new script-encoding utility provided with VBScript and JScript 5.0. Web developers can apply an encoding scheme to both client- and server-side scripts that makes the programmatic logic appear as unreadable ASCII characters. When unencoded, the logic appears in standard ASCII characters. Encoded scripts are decoded at run time by the script engine, so there's no need for a separate utility. Although this feature is not intended as a secure, encrypted solution, it can prevent most casual users from browsing or copying scripts.

IIS and Component Services

IIS 5.0 and the Component Services (COM+) included in Windows 2000 Server work together to form a basic architecture for building Web applications. In IIS version 4.0, Microsoft Transaction Server (MTS) provided transaction support. In IIS 5.0 and Windows 2000, Component Services provides all the transaction support of MTS, in addition to a number of other component development and deployment features. IIS uses the functionality provided by Component Services to:

  • Isolate applications into distinct processes.

  • Manage communication between COM components (including the ASP built-in objects).

  • Coordinate transaction processing for transactional ASP applications.

IIS and Active Directory

The Active Directory in Windows 2000 Server is used to store and manage information about networked resources. By providing a centralized store for essential information, Active Directory simplifies network management, makes it easier for users to find resources, and makes it easier for developers to write applications that require the current version of important information.

Microsoft Active Directory Service Interfaces (ADSI) is a COM-based directory service model that allows ADSI-compliant client applications to access a wide variety of distinct directory protocols, including Active Directory, LDAP, and NDS, while using a single, standard set of interfaces. ADSI shields the client application from the implementation and operational details of the underlying data store or protocol.

An application called an ADSI provider makes itself available to ADSI client applications. The data exposed by the provider is organized in a custom namespace, defined by the provider. In addition to implementing the interfaces defined by ADSI, the provider also can implement the ADSI schema. The schema is used to provide metadata about the namespace structure and objects that are provided by the ADSI provider. Administrators and application developers can add custom objects, properties, and methods to the existing ADSI provider, giving administrators more flexibility in configuring sites.

IIS currently stores most Internet site configuration information in the IIS metabase. IIS exposes a low-level DCOM interface that allows applications to gain access to, and manipulate, the metabase. To make it easy to access the metabase, IIS also includes an ADSI provider that wraps most of the functionality provided by the DCOM interface, and exposes it to any ADSI-compliant client applications.


IIS 5.0 adds performance and reliability improvements that strengthen the Web server's ability to support a broad range of requirements. In the event of a failure, it is easier to restart the server so sites can be back up and running more quickly. New application protection improves reliability. In the past, to protect the server from a misbehaving application, you had to run each application in a separate process, which could reduce performance. Now, to better balance the tradeoff between performance and protection, you can pool less-essential applications in one process, and run only essential applications in isolation. Even greater reliability can be achieved by using the clustering services available in Windows 2000 Advanced Server. Scalability is improved by support for multi-site hosting, which allows more than one Web site to run on the same server.

For administrators, a number of improvements make it easier to install and manage IIS. Before, it was relatively complicated to install IIS. Now, IIS 5.0 is installed as part of the Windows 2000 installation process. Maintenance tasks are simplified in several ways: administration utilities are accessed from a central location, there are several options for remote administration, and administrators can delegate tasks to selected users. With support for WebDAV, IIS 5.0 makes it possible for users to access and modify documents stored on a Web server, enhancing an organization's ability to use the Internet or an intranet as an aid to collaboration.

Support for new security protocols, such as Digest Authentication, Kerberos, and Fortezza lets IIS users take advantage of increasingly strong Internet security precautions. Support for these protocols extends the environments in which developers can safely deploy Internet-enabled applications.

Application developers will find that IIS 5.0 builds on prior versions of the Microsoft Web server by introducing technology to help make it easier to create more fully functioned, flexible Web sites and Web-based applications. Key improvements include better ASP flow control and faster processing for scriptless ASP pages.

The combination of Windows 2000 with IIS 5.0 makes it possible to create a full spectrum of Internet and intranet sites that take advantage of the technologies you already have in place.

Additional Resources

Microsoft Developer Network Online Library IIS SDK:

Microsoft TechNet IIS site:

Microsoft Interactive Developer Journal article: Internet Information Services 5.0: