INTERNET INFORMATION SERVICES

INTERNET INFORMATION SERVICES
IIS 6.0

Contents
Introduction 5
The Application Server Role 6
Configuring the Application Server 6
Configure Your Server Wizard 6
Add/Remove Components Application 6
IIS 6.0 Architecture—A New Request Processing Architecture 7
HTTP.sys 8
WWW Service Administration and Monitoring Component 8
Server Configuration 8
Worker Process Management 8
Worker Process Isolation Mode 8
IIS 5.0 Isolation Mode 11
Benefits of the IIS 6.0 Request Processing Architecture 12
Security Enhancements 13
Locked Down Server 13
Secure Configuration for Web Servers 13
Multiple Levels of Security 13
Table 1: Security Levels in IIS 6.0 14
Unlocking Functionality with IIS 6.0 Web Service Extensions 14
Configurable Worker Process Identity 15
IIS 6.0 Runs as a Low-Privileged Account by Default 15
SSL Improvements 15
Authorization and Authentication 16
URL Authorization and Extending the New Authorization Framework 16
Constrained, Delegated Authentication 17
Manageability Enhancements 18
XML Metabase 18
Automatic Configuration Versioning and History 19
Edit-While-Running Feature 19
Export and Import Configuration 19
Server Independent Backup and Restore 19
Metabase Auditing 20
Benefits of the IIS 6.0 XML Metabase 20
IIS 6.0 WMI Provider 20
Command-Line Administration 21
New Web-based Administration Console 21
Performance and Scalability Enhancements 22
HTTP.sys—New Kernel-Mode Driver 22
Caching Policy & Thread Management 23
Web Gardens 23
Persisted ASP Template Cache 23
Large Memory Support for x86.0 23
Site Scalability 23
Reclaiming Resources for Idle Applications 24
Application Platform Enhancements 25
ASP.NET and IIS 6.0 Integration and Variety of Language Choices 25
ExecuteURL 25
Replacing Read Raw Data Filters 25
Global Interceptors 26
ISAPI Filters 26
VectorSend 26
Caching of Dynamic Content 26
ReportUnhealthy 26
Custom Errors 27
Unicode ISAPI 27
New COM+ Services in ASP 27
Fusion Support 27
Partition Support 27
Tracker Support 28
Apartment Model Selection 28
Platform Improvements 29
64-bit Support 29
IPv6.0 Support 29
Granular Compression 29
Resource Accounting and Quality-of-Service (QoS) 29
Tracing Improvements: 30
Logging Improvements 31
UTF-8 Logging Support 31
Binary Logging 31
Logging of HTTP Substatus Codes 31
W3C Centralized Logging 31
File Transfer Protocol (FTP) 32
FTP User Isolation 32
Configurable PASV Port Range 32
Improved Patch Management 32






















Introduction
This document provides a technical overview of Internet Information Services (IIS) 6.0, the next generation Web server available in all versions of Microsoft® Windows® Server 2003. IIS 6.0 introduces many new features that can help increase the reliability, manageability, scalability, and security of your Web application infrastructure. IIS 6.0 is a key component of the Windows Server 2003 application platform, an integrated set of services and tools that enable the development and deployment of high-performance Web sites, Web applications, and Web services. The benefits of deploying IIS 6.0 include less planned and unplanned system downtime, increased Web site and application availability, lower system administration costs, server consolidation (reduced staffing, hardware, and site management costs), and a significant increase in Web infrastructure security


Topics covered in this white paper include:
• The Application Server Role
• IIS 6.0 Architecture—A New Request Processing Architecture
• New Security Features
• New Manageability Features
• New Performance and Scalability Features
• New Programmatic Features
• Platform Improvements












The Application Server Role

Application server is a new server role for the Windows Server 2003 family of products that combines together following server technologies:
• Internet Information Services (IIS) 6.0
• Microsoft .NET Framework
• ASP.NET
• ASP
• UDDI Services
• COM+
• Microsoft Message Queuing (MSMQ)
The application server role combines these technologies into a cohesive experience, giving Web application developers and administrators the ability to host dynamic applications, such as database driven Microsoft ASP.NET applications, without the need to install any other software on the server.
Configuring the Application Server
The application server is configurable in two places in Windows Server 2003: the Configure Your Server wizard and the Add/Remove Components application.
Configure Your Server Wizard
The Configure Your Server (CYS) wizard, which is a central point for configuring Windows Server 2003 roles, now includes the application server role. To access the Configure Your Server wizard, click Add or Remove Roles from the Manage Your Server page. This role replaces the existing Web server role. After this new role is installed, the Manage Your Server page, which also includes an entry for the new role.
Add/Remove Components Application
The application server is also included in the Windows Server 2003 Add/Remove Components application as a top-level optional component. Server applications that belong to the application server (IIS 6.0, ASP.NET, COM+, and MSMQ) can be installed and have their sub-components configured using Add/Remove Components. Using Add/Remove Components to configure the application server gives more granular control over the specific sub-components that will be installed.



IIS 6.0 Architecture—A New Request Processing Architecture
Web site and application code is becoming increasingly complex. Dynamic Web sites and applications might contain imperfect code that leaks memory or causes errors such as access violations. Therefore, a Web server must be an active manager of the application run-time environment and automatically detect and respond to application errors. When an application error occurs, the server needs to be fault-tolerant, meaning it must actively recycle and restart a faulty application while continuing to queue requests for the application and not interrupting the end-user’s experience. IIS 6.0 features a new fault-tolerant request processing architecture that has been designed to provide this robust and actively managed runtime, and achieve dramatically increased reliability and scalability by combining a new process isolation model, called worker process isolation mode, with performance enhancements such as kernel mode queuing and caching.
The previous version of IIS, IIS 5.0, was designed to have one process, named Inetinfo.exe, function as the main Web server process. This process transferred requests to “out of process” applications hosted in DLLHost.exe processes. In comparison, IIS 6.0 has been redesigned into two new components, a kernel-mode HTTP protocol stack (HTTP.sys) and a user-mode administration and monitoring component. This architecture allows IIS 6.0 to separate the operations of the Web server from the processing of Web site and application code—without sacrificing performance. These two major components of the IIS 6.0 fault-tolerant architecture are:
• HTTP.sys. A kernel-mode HTTP protocol stack that queues and parses incoming HTTP requests, and caches and returns application and site content. HTTP.sys does not load any application code, it simply parses and routes requests.
• WWW Service Administration and Monitoring component. A user-mode configuration and process manager that manages server operations and monitors the execution of application code. Like HTTP.sys, this component doesn’t load or process any application code.
Before discussing these components, it is important to introduce two new IIS 6.0 concepts: application pools and worker processes.
Application pools are used to manage a set of Web sites and applications. Each application pool corresponds to one request queue within HTTP.sys and the one or more Windows processes that process these requests. IIS 6.0 can support up to 2,000 application pools per server, and there can be multiple application pools operating at the same time. For example, a departmental server might have HR in one application pool and finance in another application pool. An Internet Service Provider (ISP) might have the Web sites and applications of one customer in one application pool, and the Web sites of another customer in a different application pool. Application pools are separated from other application pools by Windows Server 2003 process boundaries. Therefore, an application in one application pool is not affected by applications in other application pools, and an application request cannot be routed to another application pool while being serviced by the current application pool. Applications can easily be assigned to another application pool while the server is running.
A worker process services requests for the Web sites and applications in an application pool. All Web application processing, including loading of ISAPI filters and extensions, as well as authentication and authorization, is done by a new WWW service DLL, which is loaded into one or more host worker processes. The worker process executable is named W3wp.exe.
HTTP.sys
In IIS 6.0, HTTP.sys listens for requests and queues them appropriately. Each request queue corresponds to one application pool. Because no application code runs in HTTP.sys, it cannot be affected by failures in user-mode code that normally affect the status of the Web service. If an application fails, HTTP.sys continues to accept and queue new requests on the appropriate queue until one of the following: the process has been restarted and begins to accept requests, there are no queues available, there is no space left on the queues, or the Web service itself has been shut down by the administrator. Because HTTP.sys is a kernel-mode component, its queuing operation is especially efficient, enabling the IIS 6.0 architecture to combine process isolation with high performance request processing.
Once the WWW service notices the failed application, it starts a new worker process if there are outstanding requests still waiting to be serviced for the worker process’s application pool. Thus, while there may be a temporary disruption in user-mode request processing, an end user does not experience the failure, because requests continue to be accepted and queued.
WWW Service Administration and Monitoring Component
The WWW Service Administration and Monitoring component makes up a core portion of the WWW service. Like HTTP.sys, no application code runs in the WWW Service Administration and Monitoring component. This component has two primary responsibilities: system configuration and worker process management.
Server Configuration
At initialization time, the configuration manager portion of WWW service uses the in-memory configuration metabase to initialize the HTTP.sys namespace routing table. Each entry in the routing table contains information that routes incoming URLs to the application pool that contains the application associated with the URL. These pre-registration steps inform HTTP.sys that there is an application pool that responds to requests in a particular part of the namespace, and that HTTP.sys can request that a worker process be started for the application pool when a request arrives. All pre-registrations are done before HTTP.sys begins to route requests to individual processes. As application pools and new applications are added, the Web service configures HTTP.sys to accept requests for the new URLs, sets up the new request queues for the new application pools, and indicates where the new URLs should be routed. Routing information can change dynamically without requiring a service restart.
Worker Process Management
In the worker process management role, the WWW Service Administration and Monitoring component is responsible for controlling the lifetime of the worker processes that process the requests. This includes determining when to start, recycle, or restart a worker process, if it is unable to process any more requests (becomes blocked). It is also responsible for monitoring the worker processes, and can detect when a worker process has terminated unexpectedly.
Worker Process Isolation Mode
IIS 6.0 introduces a new application isolation mode for managing the processing of Web sites and applications: worker process isolation mode. Worker process isolation mode runs all application code in an isolated environment without incurring a performance penalty for that isolation. Applications can be completely isolated from each other, where one application error does not affect another application in a different process, using application pools. Requests are pulled directly from the kernel instead of having a user-mode process pull them from the kernel for the application, and then route accordingly to another user-mode process. First, HTTP.sys routes Web site and application requests to the correct application pool queue. Then, the worker processes serving the application pool pull requests directly from the application queue in HTTP.sys. This model eliminates the unnecessary process hops encountered when sending a request to an out-of-process DLLHost.exe and back again (as was the case in IIS 4.0 and 5.0), and increases performance.
It is important to note that, in IIS 6.0, there is no longer any notion of in-process applications. All necessary HTTP application run-time services, such as ISAPI extension support, are equally available in any application pool. This design prevents a malfunctioning Web site or application from disrupting the operation of other Web applications or the server itself. With IIS 6.0 it is now possible to unload in-process components without having to take down the entire Web service. The host worker process can be taken down temporarily without affecting other worker processes serving content. There is also a benefit from being able to leverage other operating system services available at the process level (for example CPU throttling), per application pool. Additionally, Windows Server 2003 has been re-architected to support many more concurrent processes than ever before.
Worker process isolation mode prevents one application or site from stopping another. In addition, separating applications or sites into separate worker processes simplifies a number of management tasks, for example: taking a site/application online or offline (independent of all other site/applications running on the system), changing a component the application uses, debugging an application, monitoring counters for an application, and throttling resources used by an application.
Features of IIS 6.0 worker process isolation mode include:
• Kernel-mode caching. Windows Server 2003 introduces a new kernel-mode HTTP driver called HTTP.sys, which is specifically tuned to increase Web server performance and scalability. Kernel-mode caching is available when using IIS 6.0, both in worker process isolation mode and in IIS 5.0 isolation mode (see below). As a single point of contact for all incoming (server-side) HTTP requests, HTTP.sys provides high-performance connectivity for HTTP server applications and provides overall connection management, bandwidth throttling, and Web server logging. IIS 6.0 has been built on top of HTTP.sys and has been specifically tuned to increase Web server throughput. In addition, under specific circumstances, HTTP.sys directly processes requests in the kernel. Both static and dynamic content from Web sites and applications can be cached in the HTTP.sys cache for high-performance responses.
• Clean separation between user code and the server. All user code is handled by worker processes, which are completely isolated from the core Web server. This improves upon IIS 5.0, because an ISAPI can be, and often is, hosted in-process to the core Web server. If an ISAPI loaded in a worker process fails or causes an access violation, the only thing taken down is the worker process that hosts the ISAPI. Meanwhile, the WWW service creates a new worker process to replace the failed worker process. The other worker processes are unaffected.
• Multiple application pools. With IIS 5.0, applications can be pooled together out-of-process, but only in one application pool, which is hosted by DLLHost.exe. When IIS 6.0 operates in worker process isolation mode, administrators can create up to 2,000 application pools, where each application pool can be configured separately.
• Better support for load balancers. With the advent of application pools, IIS 6.0 has a well-defined physical separation of applications; it is quite feasible to run hundreds or even thousands of sites/applications side by side on one IIS 6.0 server. In worker process isolation mode, it is important that errors in one application do not affect other applications. IIS 6.0 can also automatically communicate with load balancers/switches to route away only the traffic for a problematic application, while still allowing the server to accept requests for the other, healthy applications. For example, imagine a server processing requests for applications A and B. If application B fails so often that IIS 6.0 decides to automatically shut it down (see section on rapid fail protection below), the server should still be able to receive requests for application A. IIS 6.0 also has a built-in extensibility model that can fire events and commands when the WWW service detects a specific application’s failure. This configuration ability allows load balancers and switches to be configured to automatically stop routing traffic to problematic applications while still routing traffic to healthy applications.
• Web gardens. Multiple worker processes can be configured to service requests for a given application pool. By default, each application pool has only one worker process. However, an application pool can be configured to have a set of N equivalent worker processes that share the workload. This configuration is known as a Web garden because it is similar in nature to a Web farm, the difference being that a Web garden exists within a single server. Requests are distributed by HTTP.sys among the set of worker processes in the group. The distribution of requests is based on a round-robin scheme, where new connections with requests for the application pool are assigned to specific worker processes in that application pool. A benefit to Web gardens is that if one worker process slows down, such as when the script engine becomes unresponsive, there are other worker processes available to accept and process requests.
• Health monitoring. The WWW Service Administration and Monitoring Component monitors the health of applications by pinging worker processes periodically to determine if they are completely blocked. If a worker process is blocked, the WWW service terminates the worker process and creates another worker process in its place. The WWW service maintains a communication channel to each worker process and can easily tell when a worker process fails by detecting a drop in the communication channel.
• Processor affinity. Worker processes can have an affinity to specific CPUs to take advantage of more frequent CPU cache (L1 or L2) hits. Processor affinity, when implemented, forces IIS 6.0 worker processes to run on specific microprocessors or CPUs and applies to all worker processes serving the Web sites and applications of an application pool. Processor affinity can also be used with Web gardens that run on multiprocessor computers where clusters of CPUs have been dedicated to specific application pools.
• Allocating sites and applications to application pools. In IIS 6.0, as in IIS 5.0, applications are defined as those namespaces that are labeled in the metabase with the AppIsolated property. Sites, by default, are considered to be a simple application—where the root namespace “/” is configured as an application. An application pool can be configured to serve anything—from one Web application to multiple applications, up to multiple sites. You can assign an application to an application pool using IIS Manager or directly editing the metabase.
• Demand start. Application pools get benefits. For example, on-demand starting of the processes that service the namespace group, when the first request for a URL in that part of the namespace arrives at the server. The WWW Service Administration and Monitoring Component does on-demand process starting, and generally controls and monitors the life cycle of worker processes.
• Idle time-out. An application pool can be configured to have its worker processes request a shutdown if they are idle for a configurable amount of time. This is done to free up unused resources. Additional worker processes are started when demand exists for that application pool. (For more information, see the section on Demand Start above.)
• Rapid-fail protection. When a worker process fails, it drops the communication channel with the WWW Service Administration and Monitoring component. The WWW Service Administration and Monitoring component detects this failure and takes action, which typically includes logging the event and restarting the worker process. In addition, IIS 6.0 can be configured to automatically disable the worker process if a particular application pool suffers a configurable number of failures in a row in a configured time period. This is known as rapid-fail protection. Rapid-fail protection places the application pool in "out-of-service" mode and HTTP.sys immediately returns a 503–Service Unavailable, out-of-service message to any requests to that portion of the namespace—including requests already queued for that application pool.
• Orphaning worker processes. Worker process isolation mode can be configured to “orphan” any worker process that it deems “terminally ill.” For example, if a worker process fails to respond to a ping message in the configured time period, normally the WWW service would terminate that worker process and start a replacement. If “orphaning” is turned on, the WWW service leaves the “terminally ill” worker process running and starts a new process in its place. Also, the WWW service can be configured to run a command on the worker process (like attaching a debugger) when it “orphans” a worker process.
• Recycling worker processes. Today, many businesses and organizations have problems with Web applications that leak memory, suffer from poor coding, or have indeterminate problems. This forces administrators to restart their Web servers periodically. In previous versions of IIS, it was not possible to restart a Web site without an interruption of the entire Web server. Worker process isolation mode can be configured to periodically restart worker processes in an application pool to manage faulty applications. Worker processes can be scheduled to restart based on the following criteria: elapsed time, number of requests served, scheduled times during a 24-hour period, virtual memory usage, physical memory usage, and on demand. When a worker process wants to restart, it notifies the WWW service which then tells the existing worker process to shut down and gives a configurable time limit for the worker process to drain its remaining requests. Simultaneously, the WWW service creates a replacement worker process for the same namespace group, and the new worker process is started before the old worker process stops. This process prevents service interruptions. The old worker process remains in communication with HTTP.sys to complete its outstanding requests, and then shuts down normally, or is forcefully terminated if it does not shut down after a configurable time limit.
IIS 5.0 Isolation Mode
Some applications may not be compatible with IIS 6.0 worker process isolation mode such as applications written as read raw data filters or applications that depend on running in Inetinfo.exe or DLLHost.exe. Therefore, IIS 6.0 has the ability to run in another application isolation mode, called IIS 5.0 isolation mode, to ensure compatibility. IIS 5.0 isolation mode is very similar to IIS 5.0, because the same essential user mode processes exist. In particular, the same methods of application isolation (low, medium/pooled, and high) exist, and Inetinfo.exe is still the master process through which each request must transverse. However, despite these similarities, IIS 5.0 isolation mode benefits from the kernel-mode performance of HTTP.sys request-queuing and kernel-mode caching. Note that other IIS 6.0 services such as File Transfer Protocol (FTP), Network News Transfer Protocol (NNTP), and Simple Mail Transfer Protocol (SMTP), still work as they did in IIS 5.0 and are still contained within Inetinfo.exe. Only the WWW service in IIS 6.0 has been changed to pull requests from HTTP.sys.
Benefits of the IIS 6.0 Request Processing Architecture
The IIS 6.0 request processing architecture delivers very high levels of reliability without sacrificing performance.
• Increased reliability. IIS 6.0 worker process isolation mode prevents Web sites and applications from affecting each other or the server as a whole.
• Fewer server restarts. The user will likely never need to restart the server or shut down the entire WWW service, due to a failed application or common administration operations, such as upgrading content or components, or debugging Web applications.
• Increased application availability. IIS 6.0 supports auto restart of failed applications and periodic restart of leaky/malfunctioning applications, or applications with faulty code.
• Increased scalability. IIS 6.0 supports scaling to ISP scenarios, where there may be hundreds to thousands of sites on a server. IIS 6.0 also supports Web gardens, where a set of equivalent worker processes on a server each receive a share of the requests that are normally served by a single worker process.
• Strong application platform support. IIS 6.0 supports the application as the unit of administration. This includes making the application the unit of “robustness” by enabling application isolation, and also enabling resource throttling and scaling based on the application.










Security Enhancements
Security has always been an important aspect of Internet Information Services. However, in previous versions of the product (e.g. IIS 5.0 running on Windows 2000 Server), the server was not shipped in a “locked down” state by default. Many unnecessary services, such as Internet printing, were on at installation. Hardening the system was a manual process, and many organizations simply left their server settings unchanged. This led to widespread vulnerability to attack, because although each server could be made secure, many administrators did not realize they needed to, or did not have the tools to do so.
Microsoft has significantly increased its focus on security since the development of previous versions of IIS. For example, in early 2002, the development work of all Windows engineers—more than 8,500 people—was put on hold while the company conducted intensive security training. Once the training was completed, the development teams analyzed the Windows code base, including HTTP.sys and IIS 6.0, to implement the new knowledge. This represents a substantial investment to improve the security of the Windows platform. In addition, during the design phase of the product, Microsoft conducted extensive threat modeling to ensure that the company’s software developers understood the type of attacks that the server might face in customer deployments. Also, third-party experts have conducted independent security reviews of the code.
Locked Down Server
In order to reduce the Web infrastructure attack surface, installing Windows Server 2003 does not install IIS 6.0 by default. Administrators must explicitly select and install IIS 6.0 on all Windows Server 2003 offerings except Windows Server 2003, Web Edition. This means that now IIS 6.0 does not have to be un-installed after Windows has been installed, if it’s not necessary for the server’s role, for instance if the server is deployed to run as a mail or database server. IIS 6.0 will also be disabled when a server is being upgraded to Windows Server 2003, unless the IIS 5.0 Lockdown Tool has been installed prior to upgrade or a registry key has been configured. In addition, IIS 6.0 is configured by default in a “locked down” state when installed. After installation, IIS 6.0 accepts only requests for static files until configured to serve dynamic content, and all time-outs and settings are set to aggressive security defaults. IIS 6.0 can also be disabled using Windows Server 2003 group policies.

Secure Configuration for Web Servers
Windows Server 2003 Service Pack 1 (SP1) includes a Security Configuration Wizard (SCW), which is a role-based tool you can use to create a policy that enables the services, inbound ports, and settings required for a selected server to perform a specific role. If you select the Web Server role in the wizard, SCW configures IIS 6.0 to help further reduce the attack surface of your Web server.

Multiple Levels of Security

The following table summarizes the multiple levels of security available in IIS 6.0.
IIS 6.0 Security Level Description
Not installed by default on Windows Server 2003 Much of security is about reducing the attack surface of your system. Therefore, IIS 6.0 is not installed by default on Windows Server 2003. Administrators must explicitly select and install IIS 6.0.
Installs in a locked down state The default installation of IIS 6.0 exposes only minimal functionality. Only static files get served and all other functionality (such as ASP and ASP.NET) has to be enabled explicitly by the administrator.
Disabled on upgrades For Windows Server 2003 upgrades to servers with IIS installed, if the administrator did not install and run the Lockdown Tool or configure the RetainW3SVCStatus registry key on the server being upgraded, and then IIS 6.0 will be installed in a disabled state.
Disabling via Group Policy With Windows Server 2003, domain administrators can prevent users from installing IIS 6.0 on their computers.
Running as a low-privileged account IIS 6.0 worker processes run in a low-privileged user context by default. This drastically reduces the effect of potential attacks.
Secure ASP All ASP built-in functions always run as a low-privileged account (anonymous user).
Recognized file extensions Only serves requests to files that have recognized file extensions and rejects requests to file extensions it doesn’t recognize.
Command-line tools not accessible to Web users Attackers often take advantage of command-line tools that are executable via the Web server. In IIS 6.0, the command-line tools can’t be executed by the Web server.
Write protection for content Once attackers get access to a server, they try to deface Web sites. By preventing anonymous Web users from overwriting Web content, these attacks can be mitigated.
Time-outs and limits Product settings are set to aggressive and secure defaults.
Upload data limitations Administrators can limit the size of data that can be uploaded to a server.
Buffer overflow protection Like the rest of Windows, IIS worker processes are compiled with options that are set to monitor the Windows stack and exit the process if a buffer overflow is detected.
File verification The core server verifies that the requested content exists before it gives the request to a request handler (ISAPI extension).
Table 1: Security Levels in IIS 6.0
Unlocking Functionality with IIS 6.0 Web Service Extensions
In an effort to reduce the attack surface of your Web server, IIS 6.0 serves only static content after a default installation. Programmatic functionality provided by Internet Server API (ISAPI) extensions or Common Gateway Interfaces (CGI) must be manually enabled by an IIS 6.0 administrator. ISAPI and CGI extend the functionality of your Web pages, and for this reason are referred to as Web Service extensions. For example, in order to run Active Server Pages (ASP) with this version of IIS 6.0, the ISAPI that implements ASP.DLL must be specifically enabled as a Web service extension. Microsoft FrontPage® Server extensions and ASP.NET also have to be enabled before their functionality works. Using the Web Service Extensions feature, Web site administrators can enable or disable IIS 6.0 functionality based on the individual needs of the organization. This functionality is globally enforced across the entire server. IIS 6.0 provides programmatic, command-line, and graphical interfaces for enabling Web service extensions.
Configurable Worker Process Identity
Running multiple applications or sites on one Web server puts additional requirements on the server. If an ISP hosts two companies, who may even be competitors, on one server, it has to guarantee that these two applications run isolated from each other. More importantly, the ISP has to make sure that a malicious administrator for one application can’t access the data of the other application. IIS 6.0 provides this level of isolation through the configurable worker process identity. Together with other isolation features, like bandwidth and CPU throttling, or memory-based recycling, IIS 6.0 provides an environment to host multiple applications on one server that are completely separated. You can configure the base process identity of an application pool to be specific to the user that runs in that pool to further enhance the isolation of the pool.
IIS 6.0 Runs as a Low-Privileged Account by Default
By default, a worker process runs as a Network Service account, which is a new built-in account with exactly seven privileges:
• Adjust memory quotas for a process
• Generate security audits
• Logon as a service
• Replace process level token
• Impersonate a client after authentication
• Allow logon locally
• Access this computer from the network
Running as a low-privileged account is one of the most important security principles. The ability to exploit security vulnerability can be contained effectively if the worker process has very few rights on the underlying system. Administrators can configure the application pool to run as any account (Network Service, Local System, Local Service, or a configured account) if desired.
SSL Improvements
There are three main secure sockets layer (SSL) improvements in IIS 6.0. They are:
• Performance. IIS 5.0 already provides the fastest software-based SSL implementation on the market. As a result, 50% of all SSL Web sites run on IIS 5.0. IIS 6.0 SSL is even faster. Microsoft tuned and streamlined the underlying SSL implementation for even better performance and scalability.
• Remotable Certification Object. In IIS 5.0, administrators cannot manage SSL certificates remotely because the cryptographic service provider certificate store is not remotable. Because customers manage hundreds or even thousands of IIS servers with SSL certificates, they need a way to manage certificates remotely. The CertObject allows customers to do this.
• Selectable CryptographicService Provider. If SSL is enabled, performance drops dramatically, because the CPU has to perform a lot of intensive cryptography. However, there are hardware-based accelerator cards that enable the offloading of these cryptographic computations to hardware. Cryptographic Service Providers can then plug their own Crypto API provider into the system. With IIS 6.0, it’s easy to select such a third-party Crypto API provider.
• Kernel-Mode SSL. You can run SSL in kernel mode, instead of the default user mode. Running in kernel mode means that components or processes run in the core address space of the operating system. Moving encryption and decryption operations to the kernel improves SSL performance by reducing the number of transitions between kernel mode and user mode. Enabling kernel-mode SSL requires setting a new registry key, EnableKernelSSL.
Authorization and Authentication
If authentication answers the question “Who are you?” then authorization answers the question “What can you do?” Authorization is about allowing or denying a user to conduct a certain operation or task. Windows Server 2003 integrates .NET Passport as a supported authentication mechanism for IIS 6.0. IIS 6.0 extends the use of a new authorization framework that comes with the Windows Server 2003 family. Additionally, Web applications can use URL authorization in tandem with Authorization Manager to control access. Constrained, delegated authorization was added in Windows Server 2003 to provide domain administrators with control to allow delegation to particular machines and services only.
.NET Passport Integration with IIS 6.0
The integration of .NET Passport with IIS 6.0 provides .NET Passport authentication services in the core Web server. .NET Passport 2.0 uses interfaces provided by standard Passport components such as Secure Sockets Layer (SSL) encryption, HTTP redirects, and cookies. Administrators can make their Web sites and applications available to the entire .NET Passport customer base, which is comprised of over 150,000,000 users, without having to deal with account management issues such as password expiration or provisioning. After a user has been authenticated, the user’s .NET Passport Unique ID (PUID) can be mapped to an account in Microsoft Active Directory® directory services—if such provisioning has been configured for your Web sites. A token is created by the Local Security Authority (LSA) for the user and set by IIS 6.0 for the HTTP request. Application developers and Web site administrators can use this security model for authorization based on Active Directory users. These credentials can also be delegated by using the new Constrained Delegation feature that is supported in Windows Server 2003.
URL Authorization and Extending the New Authorization Framework
Today, access control lists (ACLs) are used to make authorization decisions. The problem is that the ACL model is very “object driven” (focused on the file, directory objects) and has been designed to fulfill the requirements of the resource manager, the NTFS file system, not the application developer. Most Web-based business applications, on the other hand, are not object driven—they are operation-based or task-based. If an application developer needs an operation-based or task-based access control model, they must create it separately. The new authorization framework in Windows Server 2003 provides a way to solve this problem. IIS 6.0 extends the use of this new tool by providing gatekeeper authorization to specific URLs. Additionally, Web applications can use URL authorization in tandem with Authorization Manager to control access from within the same policy store to URLs that are compromising a Web application, and to control application-specific tasks and operations. Maintaining the policy in the same policy store allows administrators to manage access to the URLs and application features from a single point of administration, while leveraging the store-level application groups and user-programmable business rules.
Constrained, Delegated Authentication
Delegation is the act of allowing server applications to act as the user on the network. An example of this would be a Web service application on an enterprise intranet that accesses information from various other servers in the enterprise as the client, and then presents the consolidated data over HTTP to the end user. Constrained delegation was added in Windows Server 2003 to provide domain administrators with control to allow delegation to particular computers and services only. The following are delegation recommendations:
• Delegation should not allow a server to connect on behalf of the client to any resource in the domain/forest. Only connections to particular services (for example, a backend SQL database or a remote file store) should be allowed. Otherwise, a malicious server administrator or application could impersonate the client and authenticate against any resource in the domain on behalf of the client.
• Delegation should not require the client to share its credentials with the server. If a malicious server administrator or application has your credentials, it can use them throughout the whole domain, and not just against the intended backend data store.
Constrained, delegated authentication is a highly desirable way to design an application suite in the Windows Server 2003 environment, because there are many opportunities to leverage high-level protocols such as Remote Procedure Call (RPC) and Distributed Component Object Model (DCOM). These protocols can be used to transparently carry the user context from server to server, impersonate the user context, and have the user context be authorized against objects as the user by the authorization rules, defined by: domain group information, local group information, and discretionary access control lists (DACL), on resources located on the server.












Manageability Enhancements
The typical Internet Web site no longer operates on just one server. Web sites now spread across multiple Web servers, or across Web farms. (Web farms are clusters of servers that are dedicated to delivering content, business logic, and services.) Even intranet sites have increased in number as businesses and organizations are developing and deploying more applications, especially Web-enabled, line-of-business applications. In addition, as remote administration has become more common, there has been an increasing demand to improve API access and direct configuration support. With the Internet and intranet changes over the past few years, managing a Web site is no longer as simple as managing one or a few Web servers from an office, but has become an intricate and complex process.
IIS 6.0 introduces new features to improve the administration of Web sites. The IIS 6.0 configuration store is now expressed as plain text XML, which allows for direct text editing of the metabase configuration in a robust and recoverable fashion, even while the server is running. Furthermore, Windows Management Instrumentation (WMI) support and improved command-line and scripting, enable programmatic Web site administration without the use of GUI-based IIS 6.0 Manager. IIS 6.0 also includes a new Web-based remote administration console called the Remote Administration Tool.
XML Metabase
The metabase is a hierarchical store of configuration values used by IIS 6.0 that incorporates rich functionality, such as inheritance, data typing, change notification, and security. The metabase configuration for IIS 4.0 and IIS 5.0 was stored in a proprietary binary file and was not easily readable or editable. IIS 6.0 replaces the proprietary binary file, called MetaBase.bin, with plain text XML formatted files. Administrators and application developers have long expressed the need to have an accessible, fast configuration store that doesn’t have a “black-box” feeling to it. The new XML metabase meets these needs by addressing performance and manageability through the features outlined below. Active Directory Service Interfaces (ADSI) schema and schema extensibility will continue to be supported. A human readable and editable schema supports ADSI and enhances human readability and ease of editing of the text format.
The new XML metabase improves server manageability by enabling the following scenarios:
• Direct metabase configuration troubleshooting and editing in a robust fashion
• Reuse of rich text tools such as windiff, version control systems, and editing tools
• Configuration rollback
• Versioned history archives containing copies of the metabase for each change
• Web site and application configuration cloning
• Server-independent backup and restore
The new XML metabase allows administrators to easily read and edit configuration directly without having to use scripts or code to administer the Web server. The XML metabase makes it much easier to diagnose potential metabase corruption and extend existing metabase schema via XML. In addition, administrators can read and edit current metabase configuration directly to the metabase file while still being 100% compatible with existing public metabase APIs and ADSI. The binary metabase used in previous versions of IIS will automatically upgrade to the new XML metabase used in IIS 6.0.
Automatic Configuration Versioning and History
The metabase history feature automatically keeps track of changes to the metabase that are written to disk. When the metabase is written to disk, IIS 6.0 marks the new MetaBase.xml file with a version number and saves a copy of the file in the history folder. Each history file is marked with a unique version number, which is then available for rollback or restore. The metabase history feature is enabled by default.
Edit-While-Running Feature
IIS 6.0 gives administrators the important capability to change the server configuration while the server continues running, through direct edit of the MetaBase.xml file. For example, this feature can be used to add a new site, create virtual directories, or change the configuration of application pools and worker processes—all while IIS 6.0 continues to process requests. No recompilation or restart is required. The administrator can do this easily by opening the MetaBase.xml file using Notepad, create the virtual directory needed, and save the file—again, all while IIS is running. The new changes will be detected, scanned for correctness, and applied to the metabase if the changes are per schema.
Export and Import Configuration
IIS 6.0 introduces two new Admin Base Object (ABO) methods, Export() and Import(). These methods allow the configuration from any node level to be exported and imported across servers. Secure data is protected via a user-supplied password similar to the new backup/restore support. These new methods are also available to ADSI and WMI users and through IIS Manager. Using Export() and Import() administrators can complete the following tasks:
• Export one node or an entire tree to an XML file from any level of the metabase
• Optionally export inherited configuration
• Import one node or an entire tree from an XML file
• Optionally import inherited configuration
• Password protect secure data
• Optionally merge configuration during import with existing configuration
Server Independent Backup and Restore
In IIS 6.0, a new Admin Base Object (ABO) API is available for developers to back up and restore the metabase with a password. This allows administrators and developers to create server-independent backups. The session key is encrypted with an optional user-supplied password during backup and is not based on the machine key. When backing up the metabase, the system encrypts the session key with the password supplied by the user. When restoring, the supplied password decrypts the session key, and the session key is re-encrypted with the current machine key. This new restore method can also restore backups made with the old backup method, and follows the same behavior the old restore method uses when a session key cannot be decrypted. WMI and ADSI support these methods. The existing metabase backup/restore user interface also uses the new backup/restore method.
Metabase Auditing
Beginning with Windows Server 2003 Service Pack 1 (SP1), IIS 6.0 includes a metabase auditing feature that allows tracking of each change that is made to the metabase. Metabase auditing is enabled by enabling an audit access control entry (ACE) on a node in the metabase. After the ACE is enabled, whenever a metabase change takes place on that node, an audit event is published in the NT Security event log. You can also use the new /enableaudit & /disableaudit switches on IISCNFG.vbs to enable & disable auditing. Using metabase auditing, you can keep track of:
• What was changed (metabase node, property, and old and new values).
• When the change was made (date and time).
• Who made the change (domain and user name).
• Success or failure of the change attempt (HRESULT).
• When a change is made remotely (client IP address).
Note To avoid disclosing sensitive information, such as passwords, values of secure properties do not appear in audit event log entries.
Benefits of the IIS 6.0 XML Metabase
The IIS 6.0 metabase file offers improved performance scalability. The XML metabase has comparable or better disk footprint size and faster read times on Web server startup than the IIS 5.0 binary metabase, and equivalent write performance to the IIS 5.0 binary metabase. Addition XML metabase benefits are:
• Improved backup/restore capabilities on machines that experience critical failures
• Improved troubleshooting and metabase corruption recovery
• The metabase files can be edited directly using common text editing tools
• Application configuration is exportable and importable at user-specified locations
IIS 6.0 WMI Provider
Windows 2000 introduced Windows Management Instrumentation (WMI), a new means of configuring the server and gaining access to important pieces of data such as performance counters and system configuration. IIS 6.0 now has a WMI provider, giving administrators the opportunity to use WMI capabilities, like query support and the associations between objects. WMI presents a rich set of programming interfaces that offer more powerful and flexible ways to administer your Web server. The IIS 6.0 WMI provider gives similar functionality to the IIS 6.0 ADSI provider for editing the metabase.
The goal of the IIS 6.0 WMI provider is to allow manageability of IIS 6.0 at a level of functionality equivalent to the IIS 6.0 ADSI provider and to also support an extensible schema. This requires a WMI schema that is congruent with the IIS 6.0 metabase schema. While they may differ in terms of their object and data models, ADSI and WMI offer equivalent functionality. In other words, an administration task can be scripted using either the ADSI or the WMI model. The effect on the metabase of running the same script expressed as ADSI or WMI would be equivalent. Likewise, any schema extensions done through ADSI are reflected in the WMI provider automatically.
Command-Line Administration
IIS 6.0 now ships supported scripts in the Windows\System32 directory that can be used to administer the server. These scripts, written in the Microsoft Visual Basic® scripting language, use the IIS 6.0 WMI provider to get and set configuration information within the metabase. These scripts are designed to do many of the most common tasks facing a Web administrator from the command-line without having to use a user interface. IIS 6.0 includes the following command-line administration scripts:
• IISweb.vbs: create, delete, start, stop, and list Web sites
• IISftp.vbs: create, delete, start, stop, and list FTP sites
• IISvdir.vbs: create and delete virtual directories, or display the virtual directories of a given root
• IISftpdr.vbs: create, delete, or display virtual directories under a given root
• IISconfg.vbs: export and import IIS 6.0 configuration to an XML file
• IISback.vbs: back up and restore IIS 6.0 configuration
• IISapp.vbs: list process IDs and application pool IDs for currently running worker processes
• IISext.vbs: configure Web service extensions
New Web-based Administration Console
IIS 6.0 includes a new Web-based administration console called the Remote Administration Tool. Using the Remote Administration Tool, administrators are able to remotely administer IIS 6.0 across the Internet or the intranet through a Web browser.














Performance and Scalability Enhancements
A new generation of applications puts a greater demand on performance and scalability attributes of Web servers. Increasing the speed at which HTTP requests can be processed, and allowing more applications and sites to run on one server, translates directly into fewer servers needed to host a site. It also means that existing hardware investments can be sustained longer while being able to handle greater capacity.
Windows Server 2003 introduces a new kernel-mode driver, HTTP.sys, for HTTP parsing and caching. HTTP.sys is specifically tuned to increase Web server throughput and designed to avoid a processor transition to user mode if the content requested classifies as something that can be directly processed in the kernel. This is important to IIS users because IIS 6.0 is built on top of HTTP.sys. If a user mode component needs to get involved in the processing of a request, HTTP.sys routes the request to the appropriate user mode worker process without any other user mode process getting involved in the routing decision.
IIS 6.0 is also more aware of the processing environment. IIS 6.0 kernel and user mode components are written to be aware of processor locality, and do their best to maintain per-processor internal data locality. This can add to the scalability of a server on multiprocessor systems. Additionally, administrators have the ability to establish affinity between workloads for particular applications/sites and specific processor subsystems. This means that applications can set up virtual application processing silos in the one operating system image, as shown in Figure 1 below.













Figure 1. Virtual request processing silos in IIS 6.0
HTTP.sys—New Kernel-Mode Driver
The new kernel-mode driver, HTTP.sys, is a single point of contact for all incoming (server-side) HTTP requests. This provides high performance connectivity for HTTP server applications. The driver sits atop TCP/IP and receives all connection requests from the IP/port combinations on which it is configured to listen. HTTP.sys is also responsible for overall connection management, bandwidth throttling, and Web server logging.
Caching Policy & Thread Management
IIS 6.0 has advanced heuristics built in to determine the cacheable hot-set of an application or set of sites. Just because an item is cacheable, does not necessarily mean it makes sense to add that item to an in-memory cache, because there is a cost to managing the item and the memory it consumes. Therefore, IIS 6.0 uses a new heuristic to determine which items should be cached on the basis of the distribution of requests that a particular application receives. This means that the Web server’s scalability improves because it makes better use of the resources on the server while sustaining the performance on frequent requests. IIS 6.0 also has heuristics built in to monitor the overall state of the server, and makes decisions to increase/reduce concurrency on that basis. The central idea is to be efficient in using concurrency. For example, when executing processor-bound requests, starting concurrent work is not always the best approach.
Web Gardens
A Web garden is an application pool that has multiple processes serving the requests routed to that pool. You can configure the worker processes in a Web garden to be bound to a given set of CPUs on a multi-processor system. Using Web gardens, Web applications have increased scalability because a software lock in one process does not block all the requests going to an application. If there are four processes in the Web garden, a specific software lock blocks roughly a quarter of the requests.
Persisted ASP Template Cache
Before ASP code gets executed in IIS 5.0, the ASP engine compiles an ASP file to an ASP template. These ASP templates are stored in process memory. If a site consists of numerous ASP pages, this cache de-allocates the oldest templates from memory to free space for new ones. With IIS 6.0, these templates are stored on disk. If one of these ASP files gets requested again, the ASP engine loads the template instead of loading the ASP file and spending additional CPU time compiling it again.
Large Memory Support for x86.0
For workloads that require a great deal of cached data, IIS 6.0 can be configured to cache up to 64 gigabytes (GB) for an x86 system.
Site Scalability
IIS 6.0 has improved the way internal resources are used. The IIS 6.0 approach is much more one of allocating resources as HTTP requests call for certain system resources, rather than pre-allocating resources at initialization time. This has resulted in the following improvements:
• Many more sites that can be hosted on a single IIS 6.0 server
• A larger number of worker processes that can be concurrently active
• Quicker startup/shutdown of the server when hosting sites
Preliminary testing shows an order of magnitude greater number of pooled applications can be run on IIS 6.0 as compared to IIS 5.0. IIS 6.0 is capable of having thousands of isolated applications configured, and each of these applications can run with its own application pool worker process identity. Of course, the number of concurrent isolated applications is also a function of system resources. IIS 6.0 can easily have tens of thousands of configured applications per server, when applications are configured to execute in a shared application pool.
Reclaiming Resources for Idle Applications
An additional scalability improvement in the new IIS 6.0 architecture is that IIS 6.0 can idle time-out application pool worker processes that are idle for a configured time period. If there are no requests for a given application pool over a configured time period, there is no reason that application pool should still continue to take resources. Therefore, IIS 6.0 can be configured to shut down worker processes that have been idle for a configured time period. IIS 6.0 will also trim kernel cached items for these inactive sites dynamically. Coupled together with idle time-out is the ability to demand start the worker processes when there’s demand for the application pool. While there may not be a worker process running and serving the application pool, there will be one started when the first request arrives for that application pool. In this way, IIS 6.0 is able to only consume resources when there is demand for it.



















Application Platform Enhancements
IIS 6.0 provides several new programmatic features and continues to build on the ISAPI programming model. These new features include:
• ASP.NET and IIS 6.0 integration
• Internal redirection (ExecuteURL and global interceptors)
• Buffer and handle send (VectorSend), including the ability to mark a response as cacheable in the HTTP.sys kernel cache
• Caching dynamic content: ASP.NET responses can be marked as cacheable in the HTTP.sys kernel cache; other ISAPI extensions can use the new VectorSend server support function (HSE_REQ_VECTOR_SEND) to mark responses as cacheable in HTTP.sys as well
• ISAPI support for custom errors
• Worker process recycling
• Improved ISAPI Unicode support
• New COM+ services in ASP
ASP.NET and IIS 6.0 Integration and Variety of Language Choices
Windows Server 2003 offers an improved developer experience with ASP.NET and IIS 6.0 integration. Building upon IIS 6.0, platform enhancements offer developers very high levels of functionality—for example, rapid application development and a wide variety of languages to choose from. With Windows Server 2003, the experience of using ASP.NET and the .NET Framework is improved as a result of enhanced process model integration in IIS 6.0. IIS 6.0 offers support for the latest Web standards, including XML, SOAP and IPv6.
ExecuteURL
The HSE_REQ_EXEC_URL server support function now allows an ISAPI extension to easily redirect a request to another URL. It answers growing demand by ISAPI extension developers to “chain” together requests.
Replacing Read Raw Data Filters
ExecuteURL provides functionality to replace almost all read raw data filters. The most common customer scenario for developing read raw data filters is that they want to examine or modify the request (headers or entity body) before the target URL processes it. Currently, the only way to see the entity body of a request (if you are not the target URL) is through read raw data notifications. Unfortunately, writing an ISAPI filter to accomplish this goal can be exceedingly difficult, or even impossible, in some configurations. ISAPI extensions, on the other hand, provide functionality for easy retrieval and manipulation of the entity body. ExecuteURL allows an ISAPI extension to process the request entity body and pass it to a child request, meeting the needs of nearly all read raw data filter developers.
Global Interceptors
ExecuteURL allows IIS 6.0 to implement ISAPI request interceptors that can intercept, change, redirect, or deny every incoming HTTP request for a specific URL space.
• IIS 5.0 already supports one ISAPI extension that intercepts all requests with a single wildcard (*) script map that is configured by editing the application mappings for an application.
• In IIS 6.0, the single wildcard (*) script map concept is extended to allow a multiple execution of global interceptors.
ISAPI Filters
Accepting all requests for a specific URL was a functionality that was only possible in ISAPI filters in previous versions of IIS. ISAPI filters have the following problems:
• ISAPI filters are global for a Web site.
• They can’t do long running operations (for example, database queries) without starving the IIS 6.0 thread pool.
• They can’t access the entity body of the request unless they are read raw data filters.
Because global interceptors are ISAPI extensions, they don’t have the limitations of ISAPI filters and they provide the functionality, together with ExecuteURL, to replace almost all read raw data filters.
VectorSend
Today, ISAPI developers have only two possibilities if they have multiple buffers that make up a response. They can either call WriteClient multiple times, or they can assemble the response in one big buffer.
• The first approach is a performance bottleneck, because there is one kernel-mode transition per buffer.
• The second approach costs performance too, but also needs additional memory.
VectorSend is the IIS 6.0 solution to these problems. Implemented as a server support function for ISAPIs, VectorSend allows developers to put together a list of buffers and file handles to send, in order, and then hand off to IIS 6.0 to compile the final response. HTTP.sys compiles all the buffers and/or file handles into one response buffer within the kernel and then sends it. This frees the ISAPI from having to do any of this buffer construction or multiple write clients.
Caching of Dynamic Content
Another new feature is the implementation of a kernel-mode cache for dynamic content. The benefit to this feature is that many customers have programmatically created content that doesn’t change. In previous versions of IIS 6.0, requests had to transition from kernel-mode to user mode for every dynamic request, and the responses had to be regenerated. Eliminating this transition and pulling the cached content from the kernel-mode cache results in a marked performance improvement.
ReportUnhealthy
A new ISAPI extension server support function called HSE_REQ_REPORT_UNHEALTHY allows an ISAPI extension to call into the IIS 6.0 worker process to request that worker process be recycled. Developers can use this new server support function to request a recycle if their application ISAPI becomes unstable, or enters an unknown state for any given reason.
Note In order to enable recycling after an ISAPI calls HSE_REQ_REPORT_UNHEALTHY, health monitoring should be turned on.
The developer can also pass in a string representing the reason why the ISAPI is calling HSE_REQ_REPORT_UNHEALTHY. This string is then added to the event the worker process publishes to the Application event log.
Custom Errors
ISAPI developers no longer need to generate their own error messages. Instead, they can plug into the custom error support built into IIS 6.0 through a new server support function called HSE_REQ_SEND_CUSTOM_ERROR.
Unicode ISAPI
Unicode becomes more and more important in a global economy. Due to the non-Unicode structure of the HTTP protocol, IIS 5.0 limits the developer to the system code page. With UTF-8 encoded URLs, Unicode becomes possible. IIS 6.0 allows customers to get to server variables in Unicode and adds two new server support functions to allow developers to get to the Unicode representation of a URL. International customers with multi-language sites benefit from this feature and improved development experience.
New COM+ Services in ASP
In IIS 4.0 and 5.0, ASP applications are able to use COM+ services by configuring the application’s WAM object in the COM+ configuration store to use a set of services. This was due to the fact that COM+ services were developed to be used in conjunction with COM components.
The IIS 6.0 and COM+ teams have separated the COM+ services from components and allow ASP applications to use a set of COM+ services in IIS 6.0. In addition to those services available in COM+ on Windows 2000, a few new services have been added and are supported in ASP.
Fusion Support
Fusion allows an ASP application to use a specified version of a system runtime DLL or classic COM component. Fusion allows an application developer to specify exact versions of system run-time libraries and classic COM components that work with their application. When the application is loaded and running, it will always receive these versions of the run-time libraries and COM components. Previously, applications had to use whatever version of the system runtime DLL that was installed on the system. This could present problems if a newer version is installed and has changed functionality in some way.
Partition Support
COM+ partitions allow an administrator to define a different configuration of a single COM+ application for different users. This configuration includes security and versioning information. For more information about COM+ partitions, consult the COM+ documentation.
Tracker Support
When enabled, the COM+ tracker allows administrators to monitor what code is running within the ASP session and when. This information is extremely helpful to debug ASP applications. For more information about the COM+ tracker, consult the COM+ documentation
Apartment Model Selection
ASP, through COM+, allows developers to determine which threading model to use when executing the pages in an application. By default, ASP uses the Single Threaded Apartment. However, if the application uses poolable objects, it can be run in the Multi-Threaded Apartment.

























Platform Improvements
In addition to the features described above, IIS 6.0 has made a number of improvements to the platform overall. These features make IIS 6.0 a more compelling Web application platform.
64-bit Support
The complete Windows Server 2003 family code base is compiled for 32-bit and 64-bit platforms. Customers who demand highly scalable applications can take advantage of an operating system that runs and is supported on these two platforms. In addition, Windows Server 2003, Service Pack 1 introduces a compatibility layer that enables you to run 32-bit Web applications on 64-bit Windows:
Running 32-bit Applications on 64-bit Windows

Windows Server 2003, Service Pack 1 introduces a compatibility layer, known as Windows-32-on-Windows-64 (WOW64), that is intended to run 32-bit personal productivity applications needed by software developers and administrators, including 32-bit Internet Information Services (IIS) Web applications.
On 64-bit Windows, 32-bit processes cannot load 64-bit DLLs, and 64-bit processes cannot load 32-bit DLLs. If you plan to run 32-bit applications on 64-bit Windows, you must configure IIS to create 32-bit worker processes. Once you have configured IIS to create 32-bit worker processes, you can run the following types of IIS applications on 64-bit Windows:
• Internet Server API (ISAPI) extensions
• ISAPI filters
• Active Server Page (ASP) applications (specifically, scripts calling COM objects where the COM object can be 32-bit or 64-bit)
• ASP.NET applications

IIS can, by default, launch Common Gateway Interface (CGI) applications on 64-bit Windows, because CGI applications run in a separate process.
IPv6.0 Support
Internet Protocol version 6.0 (IPv6.0) is the next generation IP protocol for the Internet. The Windows Server 2003 family now implements a production-ready IPv6.0 stack. On servers where the IPv6.0 protocol stack is installed, IIS 6.0 will automatically support handling HTTP requests that arrive over IPv6.0.
Granular Compression
On a congested network it is useful to compress responses. In IIS 5.0, compression was an ISAPI filter and could only be enabled for the whole server. IIS 6.0 allows a much more granular configuration (file level).
Resource Accounting and Quality-of-Service (QoS)
Quality-of-Service (QoS) ensures that particular components of the Web server, or specific content served by that server, don’t take over all server resources, like memory or CPU cycles. Administrators can control the resources being used by particular sites, application pools, the WWW service as a whole, and others.
Basically, QoS ensures a certain quality of service that other services, sites, or applications on the system receive. It does this by limiting the resources consumed by particular Web sites or applications, and/or by the WWW service itself.
In IIS 6.0, QoS takes the form of the following features:
• Connection limits
• Connection time-outs
• Application pool queue length limits
• Bandwidth throttling
• Process accounting
• Memory-based recycling (see above)
Tracing Improvements:
The Windows operating system includes the Event Tracing for Windows (ETW) infrastructure to help individuals troubleshoot problems in the operating system, including those involving HTTP requests in IIS components. IIS HTTP components include Active Server Pages (ASP), Internet Server Application Programming Interface (ISAPI) extensions, and the Secure Sockets Layer (SSL) Filter service, to name a few. If an HTTP request in IIS fails or becomes unresponsive while ETW is enabled, you can view ETW trace data, called events, to determine which component caused the failure.
In Windows Server 2003 Service Pack 1 or later, IIS includes the following tracing features. These features leverage the ETW infrastructure.
• IIS Currently-executing Requests Tracing: This tracing feature provides general statistics and details about all requests executing on the server at the moment tracing was started. If the CPU on your server is spiking or if requests become unresponsive, currently-executing requests tracing can help you understand which URLs are being requested, which application pool the requests reside in, and other similar details. This feature does not include the option to specify which components or URLs to trace.
• IIS Request-Based Tracing: This tracing feature tracks HTTP requests as they move through IIS components. Request-based tracing can help you target the IIS component processing a request when the request failed or became unresponsive. Request-based tracing is enabled and disabled via the command line. Request-based tracing allows you to define and trace a specific URL or a group of URLs.
Windows Server 2003 Service Pack 1 or later also includes a provider for tracing the IIS Admin service during startup and shutdown. The IIS Admin service provides access to the in-memory configuration store and other dependent services. If IIS Admin hangs on startup or shutdown, which could be due to a bad client that has registered for change notifications, and IIS Admin is waiting to cancel that notification so it can shutdown, IIS can become unresponsive. If you experience problems while IIS is starting up or shutting down, the IIS Admin Service provider can help you understand the nature of the problem.
Logging Improvements
Logging improvements in IIS 6.0 address international usage, large site, and troubleshooting scenarios by adding the following features:
UTF-8 Logging Support
With additional Unicode and UTF-8 support, IIS 6.0 now supports writing log files in UTF-8 instead of just ASCII (or local code page). This setting, configurable on the WWW service level, tells HTTP.sys how to write out the log files—in UTF-8 or in the local code page.
Binary Logging
Binary logging allows multiple sites to write to a single log file in a binary, non-formatted manner. This new logging format will offer improved performance over current text-based [World Wide Web Consortium (W3C), IIS 6.0, and National Center for Supercomputing Applications (NCSA)] logging formats since the data doesn’t have to be formatted in any specific manner. Additionally, binary logging offers scalability benefits due to the dramatic reduction in the number of log file buffers needed to log for tens of thousands of sites. When enabled, all sites will log to the same one binary log file. Tools can then be used to post-process the log file to extract the log entries. Even home-grown tools can be written to process binary log files, because the format of the log entries and file will be published.
Logging of HTTP Substatus Codes
IIS 6.0 also supports the ability to log HTTP sub status codes in W3C and binary logging formats. Sub status codes are often helpful in debugging or troubleshooting, because IIS 6.0 returns specific sub status codes for specific types of problems. For example, if a request cannot be served because the application needed has not been unlocked (like ASP by default on clean installations), the client will get a generic 404. IIS 6.0 actually generates a 404.2, which will now be logged to W3C and Binary log files.
W3C Centralized Logging
W3C centralized logging is a global configuration on the server where all Web sites write data to a single log file. Data is stored in the log file using the W3C Extended log file format. The log file can be viewed in a text editor, unlike IIS Centralized Binary Logging which writes data in binary format and requires a parsing tool to view the data. W3C centralized logging is available in Windows Server 2003 Service Pack 1 or later. By default, IIS Web sites write data to individual log files (one log file per Web site). On servers hosting large numbers of sites (hundreds or thousands), the process of maintaining large numbers of open file handles to log files can negatively impact how the server scales. W3C centralized logging improves server scalability on servers hosting large numbers of sites because IIS requires only one open file handle for logging.
W3C centralized logging is a server property, not a site property, so when you enable this feature all Web sites on that server are configured to write log data to the central log file.
Note W3C centralized logging uses the W3C Extended log format, which includes the following four fields: HostHeader, Cookie, UserAgent, and Referrer.
File Transfer Protocol (FTP)
The following FTP improvements have also been made in IIS 6.0.
FTP User Isolation
Traditionally, ISP/ASP customers have used FTP to upload their Web content because of its easy availability and wide adoption. IIS 6.0 allows the isolation of users into their own directory, thus preventing users from viewing or overwriting other users' Web content. The user’s top-level directory appears as the root of the FTP service, thus restricting access by disallowing further navigation up the directory tree. Within the user’s specific site, the user has the ability to create, modify, or delete files and folders. The FTP implementation is architected across an arbitrary number of front-end and back-end servers, which increases reliability and availability. FTP can be easily scaled, based on the addition of virtual directories and servers, without impacting the end users.
Configurable PASV Port Range
PASV FTP, or passive mode FTP, requires the server to open a data port for the client to make a second connection. This is a separate connection than the typical port 21 that is used for the FTP control channel. The port range used for PASV connections is now configurable with IIS 6.0. This feature can reduce the attack surface of IIS 6.0 FTP servers by allowing administrators to have more granular control over the port ranges that are exposed over the Internet.
Improved Patch Management
Windows Server 2003 has greatly improved patch management by offering the following new features:
• No service interruption while installing patches. The new IIS 6.0 architecture includes worker process recycling, which means an administrator can easily install most IIS 6.0 hot fixes and most new worker process DLLs without any interruption of service.
• Auto Update. Auto Update version 1.0 provides three options:
 Notify of patch availability the moment the patch is available
 Download the patch and notify of its availability
 Scheduled install (This option enables the patch to be downloaded and automatically installed at a time decided by the administrator.)
• Windows Update Corporate Edition. Many IT departments do not allow users to install security patches and other Windows Update packages without first testing them in a standard operating environment. Corporate Windows Update now enables users to run quality assurance tests on patches required by the organization. Once patches have passed the specified tests, they can be placed on the Corporate Windows Update server, behind the firewall, where all machines inside the firewall can then pick up the patch.
• Resource Free DLLs. Windows Server 2003 has now separated localization resources from the actual implementation. This has improved Microsoft’s ability to quickly design fixes for 30 languages.