IIS7 has a re-architected, unified application server engine core that handles web service messages and HTTP requests. It also boasts a new, unified application-processing model that enables developers to write applications, independent of protocol, that share a common infrastructure for caching, configuration, code deployment, dynamic compilation, event tracing, logging, security, and state management. This unified request-processing pipeline is exposed to developers writing in native (C/C++) and managed (ASP.NET) code.

Not only does IIS7 represent a powerful platform with which to directly build Web and other Internet solutions, but it also provides the core infrastructure upon which many of Microsoft's communication technologies and services are built, including ASP.NET, WCF, and Windows SharePoint Services. In addition, because of its flexible, modular nature, it can be easily extended to support new third-party technologies and services.

The IIS7 core Web server has undergone fundamental changes. In contrast to the monolithic design of past releases, IIS7 is now factored into over 40 feature modules. This modularization enables administrators and developers to customize in a fine-grained manner exactly which features should be installed and running on their Web server, dramatically reducing the security attack surface of the server.

A new Win32 API is available for building core server modules, a new and more powerful alternative to ISAPI filters (although filters are still fully supported). All of the existing IIS core-server features have been ported on top of this new Win32 API as feature modules, enabling developers to add, remove, and even replace IIS feature modules.

These server modules play two general roles: request services (for example, authentication or output caching, similar to ISAPI filters) and request handling (for example, static file handling, CGI, or ASP.NET page processing, similar to ISAPI extensions).

IIS7 enables developers to extend IIS to provide custom functionality in new, more powerful ways. Extensibility begins with an all-new core server API set, which supports both native (C/C++) and managed (ASP.NET using the IHttpModule interface) feature module development. This approach provides developers with a flexible way to extend the core server’s HTTP processing pipeline. Managed code modules have full access to all events in the request pipeline, for all requests. This level of integration is unprecedented and allows existing ASP.NET features, such as forms-based authentication or URL authorization, to be used for all types of Web content.

IIS7 also enables extensibility of configuration, scripting, event logging, and administration tool feature sets, providing software developers a complete server platform on which to build powerful, completely new functionality.

IIS7 enables developers and IT professionals to more easily troubleshoot errant Web sites and applications. IIS7 provides a clear view of internal diagnostic information, and collects and surfaces detailed diagnostic events to aid in troubleshooting problematic servers. IIS7 includes two major advances that aid in diagnostics and troubleshooting: access to real-time information and greatly enhanced tracing functionality.

A new Run-Time Status and Control (RSCA) API provides real-time state information about application pools, worker processes, sites, application domains, and even running requests. This COM API is exposed via Windows Management Interface (WMI) and the new IIS Manager (inetmgr.exe) for quick and easy status regardless of the management environment. For more information and sample code on obtaining RSCA data, see Overview of Runtime Status and Control Data and Objects (RSCA) and How to Access IIS7 RSCA Data.

Detailed trace events throughout the request and response path allow developers to trace a request as it makes it way to IIS, through the IIS request-processing pipeline, into any existing page level code, and back out to the response. These detailed trace events allow developers to understand not only the request path and any error information that was raised as a result of the request, but elapsed time and other debug information to assist in troubleshooting all types of errors. To enable the collection of these trace events, IIS7 can be configured to automatically capture full trace logs for any given request based on elapsed time or error response codes. This functionality enables developers to configure IIS to watch for hard-to-reproduce error conditions and automatically trap the error with a detailed trace log. This "failed request tracking" capability is also available to managed applications through the standard System.Diagnostics.Trace mechanism. For more information, see Troubleshooting Failed Requests using Tracing in IIS7.

IIS7 enables Web-hosting and IT professionals to safely and securely delegate fine-grained administrative control to developers and content owners, reducing the cost of ownership and administrative burden for the administrator. IIS7 enables administrators to delegate configuration tasks to developers, and supports delegated administration of sites and applications through the IIS Manager. It unifies the management of traditional Web and ASP.NET solutions, and state is stored in separate XML-based configuration files, based on the model of the .NET Framework configuration store.

For Windows Server® 2003 and Windows Server 2008, IIS7 eases the deployment and management of content and configuration data in server-farm scenarios. IIS7 provides an easy way for Web-site and application configuration to be copied between servers. Configuration information can now be shared across multiple front-end servers, avoiding costly and error-prone replication and manual-synchronization issues that plague today's administrators.

The IIS administration tool is designed to support tens of thousands of applications on a single server or across server farms. It supports delegated administration scenarios where non-computer administrators can manage sites locally. It also provides a programmer's framework to extend its operation and to seamlessly integrate additional semantics and support within the tool. For example, the tool's built-in support for IIS, ASP.NET and WCF was provided through this framework.

To enhance the development and hosting of Web services over many protocols, IIS7 is compatible with the Windows Activation Service (WAS), which supports pluggable activation of arbitrary protocol listeners. WAS provides all types of message-activated applications with intelligent resource management, on-demand process activation, health-monitoring, and automatic failure detection and recycling. WAS is based on the IIS6 and IIS7 request-processing model.

Configuration

Administration Tool

IIS7 is built to be compatible with the vast majority of existing solution technologies, including:

• All existing ISAPI extensions and most ISAPI filters will continue to work, unchanged. As in IIS6.0, the one exception is that ISAPI filters that rely on READ_RAW notification are no longer supported.

• All existing ASP, ASP.NET 1.1, and ASP.NET 2.0 applications are expected to run on IIS7 without any code changes (using the compatible ISAPI support).

• For existing Active Directory Service Interfaces (ADSI) and WMI scripts, IIS7 provides feature parity with previous releases, enabling them to run directly against the new configuration store.

The core server provides an execution engine that drives the processing of HTTP requests and related services. It operates by invoking modules during a number of server events and providing them with the state and APIs necessary to perform useful work in the server environment. Each such invocation is referred to as a notification.

The event model used by the server is comprised of two major event types:

• Request events—specific events that correspond to each stage of the request processing pipeline (deterministic events) or events that occur as a consequence of an API call or an operation that takes place during the request (non-deterministic events). For example, the AuthenticateRequest event is associated with the authenticate stage of the pipeline. The result of this stage is the determination of a set of credentials to be associated with the request.

• Global events—used to notify modules of server events that are not associated with particular requests. They serve as a provider mechanism that allows the server to delegate a particular non-request related task to modules. For example, a TraceEvent notification allows a server trace event to occur at any time.

The core server maintains a list of modules that have registered for each event, and when the event is raised, generally delivers a notification to each of these modules. The notification contains information about the notification, the module being notified, and a provider object that is event-specific and allows the module to interact with the server in a way specialized to the event. A notification might not be delivered to a registered module under the following circumstances:

• The module has been administratively disabled for the current application. If a module is not referenced in the <modules> element of the <system.webServer> section of the configuration file for a given application, it will not receive notifications for request events in this application.

• One or more of the module's execution preconditions fail, signaling to the server that the module is not interested in events during the current precondition scope (usually the current request). Preconditions can be specified in either the <modules> or <handlers> configuration sections.

• The module opted out of further notifications for the duration of the current request by calling the IHttpContext.DisableNotifications method.

• Another module, which occurred earlier in the processing chain, has handled the event by returning HANDLED or aborted the processing of the request by returning FINISH_REQUEST. Note that HANDLED can only be returned for request event notifications and are not allowed in POST notifications. Also note that LogRequest and EndRequest events are always executed and do not allow FINISH_REQUEST or HANDLED values to be returned from them.

IIS7 enables further specialization of notification handling. For example, notification handling can be merged and notification priority can be changed.

Each pipeline stage has two events: the main event representing the beginning of the stage and an associated event that occurs at the end of the stage. The end stage event has "Post" prepended to the main event name. The core server engine issues the following events, which represent a small superset of the ASP.NET event model. These events are available to native code developers. The events available to managed code developers are similar but not completely analogous. For more information, see Comparing Native-Code and Managed-Code Notifications.

Global events do not have an associated post event.