Version Differences in IIS Administration Features

This topic describes important differences is IIS programmatic adminstration technologies between IIS 4.0, IIS 5.0, IIS 5.1, and IIS 6.0.

One of the most important changes in IIS 6.0 addresses Web server security. In order to take a more proactive stance against malicious users and attackers, IIS is not installed on members of the Microsoft Windows Server 2003 family by default.

For more information about IIS 6.0 security, see "Security" in IIS Help, which is accessible from IIS Manager or from Internet Information Services 6.0 Product Documentation.

When you initially install IIS 6.0, the service is installed in a highly secure and "locked" mode. By default, IIS serves only static content. This means that features like ASP, ASP.NET, Server-Side Includes, WebDAV publishing, and FrontPage Server Extensions do not work. You can serve dynamic content and "unlock" these features through the Web Service Extensions node in IIS Manager, or by using the iisext.vbs command-line tool. For more information about the initial state of IIS, see "Enabling and Disabling Dynamic Content" in IIS Help, which is accessible from IIS Manager.

In This Topic

This topic includes information on the following:

• Core Functionality and Services

• Metabase Configuration

• Administration

• Programmatic Administration

• ASP Hang Detection

• Security

• Performance

• IIS Administration Interfaces

Summary

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

Core Functionality and Services

• IIS 6.0 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: IIS 5.0 isolation mode and worker process isolation mode.

• IIS 6.0 is built in unicode. If you have an application that utilizes ANSI processes, it will fail in IIS 6 Worker Process Isolation Mode because MFC.DLL is ANSI and it is compiled to use the __argv global. The IIS W3WP.exe process is built in unicode and it is compiled to use the __wargv parameter.

IIS 5.0 Isolation Mode

IIS 5.0 isolation mode manages application processes in a similar fashion to the process management in IIS 5.0: all in-process applications run inside Inetinfo.exe, and out-of-process applications run in separate DLL hosts. Some existing applications may not have been written to run concurrently, or store state separately from the application. Therefore, running processes in IIS 5.0 isolation mode ensures compatibility for most existing applications.

The following illustration shows how application processes are handled in IIS 5.0 isolation mode.

Worker Process Isolation Mode

When configured to execute in worker process isolation mode, all application code runs in an isolated environment. This design removes some of the existing bottlenecks. Worker process isolation mode allows the administrator to isolate anything from an individual Web application to multiple sites in their own self-contained World Wide Web Publishing Service (WWW 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 worker process isolation mode.

HTTP requests are routed to the correct application pool queue, which means that 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 DLL host. 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 becomes easier because with isolated application processes, the process can, if necessary, be terminated to unload all resources, with no effect on other content or applications being served from other processes. It is also beneficial to be able to leverage other operating system services available at the process level (for example CPU throttling), per application pool.

Furthermore, critical portions of worker process isolation mode that maintain the overall functioning of WWW 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 WWW Service Administration and Monitoring component 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 WWW services on the server.

For more information on isolation modes, see "IIS Isolation Modes" in IIS Help, which is accessible from IIS Manager.

Metabase Configuration

The metabase for IIS 6.0 is stored in an XML file instead of in binary format as 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.

For more information about the IIS metabase, see About the Metabase.

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 be grouped into pooled processes for increased performance and improved scalability. For more information, see "Web Application Isolation" in IIS Help, which is accessible from IIS Manager. In IIS 6.0 dedicated application mode, applications can pooled in any number of application 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" in IIS Help, which is accessible from IIS Manager.

• Clustering is not a feature of IIS 6.0, and IISsynch.exe has been removed. Clustering is a feature of the Windows Server 2003 family. For information on Windows Clustering (MSCS), see the Help that comes with Windows Server 2003.

• 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" in IIS Help, which is accessible from IIS Manager.

• New custom error files exist to report more detailed errors, as well as errors related to new features. For a complete list of available custom error messages, see "About Custom Error Messages" in IIS Help, which is accessible from IIS Manager.

• The Web-based Internet Services Manager (HTML) has been replaced by a Web Server Appliance Kit (SAK). To remotely administer IIS using the Internet Services Manager (HTML), see "How to Administer the Server Remotely" in IIS Help, which is accessible from IIS Manager.

Programmatic Administration

• In previous versions of IIS, programmatic administration of IIS was possible with Admin Base Objects (ABO) from compiled C++ applications, or with Active Directory Services Interfaces (ADSI) from C++ or script files. IIS 6.0 comes with a provider for Windows Management Instrumentation (WMI), a technology that allows administrators to control all services and applications programmatically. See Using the IIS WMI Provider for more information.

• Windows Server 2003 SP1 or later, Windows XP SP2 or later: Network encryption for WMI is on by default. If you create an application or script that is intended to administer IIS on a remote computer running Windows Server 2003 SP1 or later, you must use the AuthenticationLevel property. WMI-based scripts that do not encrypt the connection when administering IIS remotely fail with an Access Denied error (WBEM_E_ACCESS_DENIED, 0x80041003). For information on how to configure encryption in WMI-based scripts, see Encrypting Data When Running WMI-Based Remote Administration Scripts in the IIS Administration Guide.

• When using ADSI to configure IIS, ensure that the user account of the person running the script is a member of the administrators group. When you are using the WinNT provider, we recommend that you authenticate with the target server by logging onto a domain account with appropriate credentials or using the LogonUser function (which requires elevated privileges) prior to executing your ADSI code. For more information, see User authentication issues with the ADSI WinNT provider and INFO: Security Ramifications for IIS Applications.

ASP Hang Detection

When an IIS Web site is busy, there may be instances when the maximum number of ASP threads has been spawned and some of the ASP threads are unresponsive, resulting in degraded performance. IIS 6.0 has the ability to solve the problem of unresponsive threads by recycling the worker process that hosts that particular instance of the ASP ISAPI extension, ASP.dll. When ASP threads are unresponsive in IIS 6.0, ASP.dll calls the ISAPI server support function HSE_REQ_REPORT_UNHEALTHY, and the WWW service will recycle the worker process that hosts ASP.dll, and make an entry in the event log.

For more information on ISAPI Server Support Functions, see ServerSupportFunction in the IIS ISAPI Extensions.

Security

One of the most important changes in IIS 6.0 addresses Web server security. See "Security" in IIS Help, which is accessible from IIS Manager. In order to take a more proactive stance against malicious users and attackers, IIS is no longer installed by default on Microsoft Windows Server 2003 family systems. Furthermore, when you initially install IIS, it is installed in a highly secure and "locked" mode.

By default, IIS serves only static content, which means that features like ASP, ASP.NET, Server-Side Includes, WebDAV publishing, and FrontPage Server Extensions do not work. You can serve dynamic content and "unlock" these features through the Web Service Extensions node in IIS Manager, or by using the iisext.vbs command-line tool. For more information about the initial state of IIS, see "Enabling and Disabling Dynamic Content" in IIS Help, which is accessible from IIS Manager.

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 see "Using the New Security Task Wizards" in IIS Help, which is accessible from IIS Manager.

Other security changes in IIS 6.0:

• 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.

• Sub-authentication is no longer enabled by default on a new installation of IIS 6.0. For more information, see AnonymousPasswordSync.

• FrontPage Web, which allows administration of sites on your server by using FrontPage, is no longer set in IIS Manager. It is enabled by default.

• Fortezza support has been removed.

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 compilation 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.

IIS Administration Interfaces

• The IADMEXT interface was removed from IIS 6.0. This interface contained methods called Initialize, EnumDcomCLSIDs, and Terminate. It was used to synchronize configuration data and content between one IIS server and another. On IIS 6.0, you can install Application Center 2000 to synchronize configuration data and content in a Web farm environment.

• The IMSAdminReplication was removed from IIS 6.0. This interface contained methods called DeSerialize, GetSignature, GetSignature, Propagate, GetSignature, Propagate, Propagate2, and Serialize. It was used to replicate configuration data from one IIS server to another. On IIS 6.0, you can use the Metabase Import and Export feature to perform this task using the IIS Manager or using scripts.

See Also

Concepts

Version Differences in IIS Web Application Features