[This is preliminary documentation and subject to change]

What's Changed

This topic describes important differences in default behavior and settings between IIS 4.0, IIS 5.0, IIS 5.1, and IIS 6.0.

The following table summarizes the important differences between versions of IIS.

	IIS 4.0	IIS 5.0	IIS 5.1	IIS 6.0
Platform	NT4	Windows 2000	Windows XP Professional	Windows Whistler Servers
Architecture	32-bit	32-bit	32-bit	32- and 64-bit
Application process model	TCP/IP kernel, Dll Host	TCP/IP kernel, Dll Host	TCP/IP kernel, multiple Dll Hosts	Http.sys kernel, multiple worker processes
Metabase configuration	Binary	Binary	Binary	XML
Security	Windows authentication	Windows authentication Kerberos SSL	Windows authentication Kerberos SSL Security wizard	Windows authentication Kerberos SSL Security wizard Passport support
Remote administration	Not supported	HTMLA	No HTMLA Terminal services	No HTMLA Terminal services
Cluster support	None	IIS clustering	Windows support	Windows support
Web services	IIS on NT 4.0	Personal Web Manager on Windows 9x IIS on Windows 2000	IIS optionally on Windows XP Professional IIS on Windows 2000	IIS on Windows Whistler Servers

For information about new features in IIS 6.0, see Features.

Core Functionality and Services

Metabase Configuration

Administration

Programmatic Administration

Active Server Pages (ASP)

Registry

Security

Performance

Core Functionality and Services

IIS 6.0 Functionality and Services

IIS has been redesigned to take advantage of the base Windows kernel, Http.sys. This allows for built-in response and request caching and queueing, and the ability to route application process requests directly to the worker processes, improving reliability and performance.

IIS 6.0 introduces two modes of operation in order to configure your application environments: standard application mode and dedicated application mode.

Standard Application Mode

Standard application mode manages application processes similar to the process management in IIS 5.0: all in-proc processes run inside inetinfo, and out-of-proc applications run in separate DLL Hosts. Some existing applications may not have been written to run concurrently, or store state separately from the applicaiton. Therefore, running processes in standard application mode ensures compatability for most existing applications. The following illustration shows how application processes are handled in standard application mode.

Standard application mode.

Dedicated Application Mode

When configured to execute in dedicated application mode, all application code runs in an isolated environment. This design removes some of the existing bottlenecks and points of contention. Dedicated application mode allows the administrator to isolate anything from an individual Web application to multiple sites in their own self-contained Web service process. This prevents one application or site from stopping another. In addition, separating applications or sites into their own process space simplifies a number of management tasks, such as restarts (independent of all other sites or applications running on the system), changing a component used by the application, debugging, monitoring counters, throttling resources, and so forth. The following illustration shows how applications are managed by IIS in dedicated application mode.

Dedicated application mode.

HTTP requests are routed to the correct application pool queue: user mode worker-processes serving a pool pull the requests directly from the kernel and eliminate the unnecessary process hops encountered when sending a request to an out-of-process DLLhost. In IIS 6.0, there is no longer the notion of in-process applications; all necessary HTTP application runtime services, such as ISAPI extension support, are equally available in any application pool. This design prevents a malfunctioning HTTP application or Web site from disrupting other HTTP applications (or other Web sites) served from other processes on that computer. Unloading components become easier, because with isolated application processes, the process can, if necessary, be terminated to unload all resources, without affect on other content or applications being served from other processes. There is also benefit from being able to leverage other operating system services available at the process level (for example CPU throttling), per application pool.

Furthermore, critical portions of dedicated application mode that maintain the overall functioning of Web services run entirely outside of the worker processes. The IIS 6.0 kernel mode driver, Http.sys, which is the universal HTTP processor for Windows, and the IIS 6.0 Web administration service (WAS) isolate the critical portions of the core Web server. Both of these components are protected and do not allow third-party code to be loaded into them. This design prevents a malfunctioning HTTP application from disrupting Web services on the server.

Metabase Configuration

The metabase for IIS 6.0 is stored in an XML file instead of binary format in past versions. The location remains the same, but the ways it can be manipulated - updated, rolled back, restored, extended - have changed. There are two significant files instead of one: Metabase.xml and MBSchema.xml.

Administration

In IIS 4.0, applications could either be run in the same process as the Internet service or in a separate process. In IIS 5.0 and 5.1, applications can now be grouped into pooled processes for increased performance and improved scalability. For more information, see Application Protection in the About Applications topic. In IIS 6.0, dedicated application mode, applications can pooled in any number of applicaiton pools.
The Application Mappings property sheet contains a list of Hypertext Transport Protocol (HTTP) verbs that will be processed by an application that is mapped to certain file types. This list of verbs represents a change from IIS 4.0. In IIS 4.0, the list contained verbs that were excluded, or not processed. This change was made to accommodate new HTTP verbs as they are added to the Protocol. For more information on application mappings, see Setting Application Mappings.
Clustering is not a feature of IIS 6.0 (IISsynche.exe is not supported). Clustering is a Windows Whistler feature. For information on Microsoft Windows Clustering Services (MSCS), see the Windows Whistler Help documentation.
The location of custom error files has changed from IIS 4.0 to IIS 5.0. For more information, see Enabling Detailed Custom Error Messages.
The Web-based Internet Services Manager (HTML) has been replaced by a web applicance. To remotely administer IIS by using the Internet Services Manager (HTML), see Remote Administration.

Programmatic Administration

See Metabase Changes for IIS 6.0.

Active Server Pages (ASP)

See Important Changes in ASP.

Security

Many of the security features available in IIS 4.0 have been simplified in IIS 5.0, 5.1 and IIS6.0, which have new security task wizards: the Permissions Wizard, the Web Server Certificate Wizard, and the CTL Wizard. With these three wizards, you can synchronize Web and NTFS security settings, obtain and install server certificates, and create and modify certificate trust lists. In IIS 5.1 and IIS 6.0, you can select a cryptographic service provider (CSP) for encrypting data with a certificate. For more information, see Using the New Security Task Wizards.
Index this resource is now enabled by default.
Script source access, which allows access to the source code of scripts in ASP pages and other scripts, is new and is disabled by default. It is available only if either Read or Write permission is selected.
FrontPage Web, which allows administration of sites on your server by using FrontPage, is no longer set in the IIS snap-in. It is enabled by default.

Performance

To limit the amount of memory allocated to ASP pages, IIS has set the default value of AspScriptFileCacheSize to 250 ASP pages, and the default value of AspScriptEngineCacheMax to 125 script engines. The ASPScriptFileCacheSize can be set higher on sites with a large set of frequently requested ASP pages. This improves performance because ASP page compriation is substantially slower than retrieving pages from cache. On a site with only a small number of frequently requested ASP pages, memory can be saved by setting this number to a smaller value.