Developer Story Internet Information Services

An Internet Information Services Roadmap

Windows Vista® and Windows Server® 2008 deliver a unified Web platform that provides integrated support for Internet Information Services (IIS), ASP.NET, Windows Communication Foundation (WCF), and Windows SharePoint Services. IIS7 is a major enhancement to the Windows Web server and plays a central role in unifying the Web platform. The key pillars of the IIS7 release are:

• A unified platform that delivers a single, consistent developer and administrator model for Web solutions.

• Enhanced security and smaller, independent components to reduce attack surface.

• Flexible extensibility to enable powerful customization.

• Simplified problem resolution through powerful diagnostics and troubleshooting.

• Delegated administration for hosting and enterprise workloads.

• Improved support for server farms.

• Integrated application and health management for Web services.

• Improved configuration and administration tools.

• Compatibility with existing solution technologies.

Unified Platform for Web Services

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.

Enhanced Security and Performance Through Componentization

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

Flexible Extensibility Model for Powerful Customization

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.

Rich Troubleshooting Tools and Diagnostic Information

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.

New Delegated Administration

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.

Improved Support for Server Farms

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.

Application and Health Management for Web Services

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.

Improved Configuration and Administration Tools

Configuration

IIS7 introduces major improvements to the way that configuration data is stored and accessed. One of the key goals of IIS7 is to enable distributed configuration of IIS settings, allowing developers to specify IIS configuration settings alongside code and content.

Distributed configuration enables many powerful new capabilities with IIS7. It enables developers to specify configuration for a Web site or application in the same directory as the code or content. It allows configuration for a particular site or application to be copied from one computer to another as the application moves from development into test and ultimately into production. Distributed configuration also enables configuration for a site or application to be shared across a server farm; all configuration and content is accessed through a back-end file server.

IIS7 configuration is based on the existing .NET Framework configuration store, which enables IIS configuration settings to be stored alongside ASP.NET configuration in Web.config files. This change provides one configuration store for all Web platform configurations that is accessible via a common set of APIs and stored in a consistent format. The IIS7 configuration system is fully extensible, so developers can extend the configuration store to include custom configuration with the same fidelity and priority as IIS configuration.

IIS7 stores global or computer-wide configuration in the file %windir%\system32\inetsrv\config\ApplicationHost.config. In this file there are two major configuration section groups:

• system.applicationHost contains configuration for site, application, virtual directory, and application pools.

• system.webServer contains configuration for all other settings, including global defaults.

URL specific configuration can also be stored in ApplicationHost.config using the <location> element. IIS7 can also read and write URL-specific configuration within the code or content directories of the Web sites and applications on the server in Web.config files, alongside ASP.NET configuration.

IIS7 includes a new WMI provider that broadens scripting access to all IIS and ASP.NET configuration. The IIS6 command-line scripts have also been replaced with a new, powerful command-line utility.

Administration Tool

IIS7 includes a completely rewritten administration tool for managing IIS: the IIS Manager (inetmgr.exe or iis.msc). IIS Manager fully supports the distributed configuration support introduced above, allowing for delegated (non-administrative) access to configuration for individual sites and applications. IIS Manager supports non-administrator and even non-Windows credentials to authenticate to a particular site or application, and manage configuration for just that scope.

IIS Manager has been carefully designed to provide an easier, more task-based workflow for managing IIS, with common management tasks. IIS Manager covers all of IIS and ASP.NET configuration, with support for ASP.NET 2.0's Membership and Role Manager features.

IIS Manager supports remote administration over HTTP, allowing for seamless local, remote, and even cross-Internet administration without requiring that DCOM or other administrative ports be opened on the firewall.

IIS Manager is fully extensible, enabling developers to build new administration modules using the .NET Framework to easily plug in first-class administration UI just like the IIS team.

For more information, see Getting Started with IIS Manager.

Compatibility

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.

Deprecated and Obsolete IIS Features

IIS7 no longer supports the following features found in IIS6:

• IIS5 isolation mode—IIS6 supported this IIS5 emulation mode through the IIS5IsolationModeEnabled metabase property to assure compatibility with applications developed for IIS5.1 and older. IIS7 supports only the native isolation mode, called worker process isolation mode. This mode enables application pooling, recycling, and health detection features.

  This change was necessitated because of a change in the underlying features of HTTP.sys. READ_RAW filter support, upon which IIS5 isolation mode depends, has been eliminated.

• By default, the Internet Data Connector (IDC) extension (HttpOdbc.dll) is unmapped, disabling the use of legacy IDC scripts to query ODBC databases. This functionality has been superseded by full query libraries, including those provided by ASP and ASP.NET.

• Automatic metabase account recreation is eliminated. Previously, during IISAdmin service startup, the Anonymous and WAM user accounts were recreated if they were absent. In Windows Vista and Windows Server 2008, these built-in accounts cannot be deleted, so this capability is no longer needed.

• Server-side image maps are no longer supported; client-side image maps are now universally supported by browsers.

• Sub-authentication has been eliminated. This feature enabled IIS to log on a principal without having a password. This feature works only if the process that loads it runs under the LocalSystem account, which is a security risk.

• The ASP Content Rotator and Nextlink components are unavailable because they are rarely used.

• The Convlog tool, which converts log files to the NCSA log file format, is obsolete and has been discontinued. Its functionality can be completely replaced by a simple LogParser script.

• The PICS content rating UI, which easily enables a server administrator to rate content for violence, sex, nudity, and language, has been discontinued. PICS is not a widely used rating system.

• Microsoft Passport support has been discontinued in favor of newer WebSSO technologies.

• The support for clustering IIS4 and IIS5 through the IIS Cluster Admin Tool extension (iisclex4.dll) has been discontinued.

• IIS7 will not run on Windows Server 2003.

• SSINC command execution, which was disabled by default in IIS6, has been completely removed for security reasons.

• The IISRESET –reboot command has been removed because it is superseded by the new Windows Shutdown API.

• IIS7 does not include support for Web sharing, a feature that previously allowed users to make Window Explorer folders into virtual Web folders. Instead, users should use the IIS Manager to create and manage Web folders.

Inside IIS: An Application Developer's View

IIS7 introduces large changes in development, configuration, and diagnostics capabilities and associated APIs to meet the needs of both application developers and administrators. Although there is quite a bit of overlap in usage, it is useful to separate these new technologies into two groups:

Administration and Monitoring

Technology	Description
Configuration files and IIS7 settings schema	The XML-based configuration of IIS, ASP.NET, and WCF settings, which are based on the .NET Framework configuration storage model. These files can be edited manually, programmatically, or through administration tools to configure Web servers and resident Web applications. Note that computer administrators can now delegate the authority to modify configuration files on a very granular basis. Most of the Web metabase properties in IIS6 are directly mapped to configuration settings in IIS7 schema. For more information, see "IIS 7.0 Web Administration Reference" in the Windows SDK.
Native Configuration Reader API	A C++ API for working with the new configuration settings files and their standard schema.
IIS Manager development (Web Management Framework)	The set of managed classes in the Microsoft.Web.Management.Server, Microsoft.Web.Management.Client, and Microsoft.Web.Management.Host namespaces that support the creation of extensions so that custom objects and services can be managed alongside standard ones in hosts such as the IIS Manager (inetmgr.exe).
Run-Time Status and Control (RSCA) API	A COM API that provides real-time state information about and control over application pools, worker processes, sites, application domains, and running requests. This API is exposed via WMI and the new IIS Manager for quick and easy status regardless of the management environment. This API does not expose configuration information.
Windows Process Activation Service (WAS) API	A C++ API that provide access to process activation, management, and monitoring capabilities. This API is especially important for hosting Windows Communication Foundation processes that use non-HTTP protocols (TCP, named pipes, or MSMQ).
Managed Application Hosting and Management (WebHost) API	An API that hosts and manages all managed code applications that can be activated by messages, including ASP.NET and WCF applications. Specifically, WebHost manages activation and lifetime of worker processes, application domains, and application components and provides a set of common application services (for example, configuration, dynamic compilation, and caching). WebHost includes components provided by IIS, ASP.NET, and WCF. The WebHost API is located in the System.Web.Hosting namespace.

Note

The Native Configuration Reader and WAS APIs are low-level interfaces that are primarily used within the framework infrastructure.

Application Development and Diagnostics

Technology	Description
Core module extensibility APIs	APIs that enable the development of new modules that extends IIS. Both native and managed APIs are provided. These APIs can largely replace older means of extending IIS, including ISAPI filters and extensions and CGI. IIS7 Native-Code Web Server Core API: a C++ API that supports the development of extension modules through the implementation of the RegisterModule function and a class derived from CHttpModule. ASP.NET (managed-code) Extensibility API: the existing System.Web.IHttpModule and IHttpModule interfaces now enable the creation of managed IIS extension modules.
Http Server API	A kernel-mode Win32 API that enables developers to develop and extend the Web service, with or without the presence of IIS. (A managed interface is also available through the System.Net.HttpListener class.) The HTTP protocol stack listener driver, Http.sys, is a kernel-mode networking component that acts as a preprocessor and router for all Web requests, including security, logging and tracing, caching, and Quality of Service (QoS) functions.
IIS Hosted Web Core API	Two Win32 functions that enable third-party applications to load an instance of the IIS core. Such an instance requires a separate configuration file and is limited to hosting a single application pool.
Caching interfaces	A set of C++ interfaces that enable access to the global file, token, and URI caches.
Listener Adapter API	A Win32 API for the creation and control of listener adapters, which are a standard IIS component used to establish a communication channel between protocol listeners and the hosting process (WAS or Http.sys).
IIS Worker Process Framework API	A protocol-independent C++ API that enables protocol managers and the associated worker processes to exchange information. Protocol managers are responsible for starting and stopping listener channels for a protocol, and gathering health-related and RTSC information.
IIS Tracing API	Enumerations and structures used by the new IIS Web tracing infrastructure.

The IIS Hosted Web Core API can be leveraged by third-party platform developers to integrate the IIS core engine capabilities to serve Web pages, provide security services, process isolation, and so on. The caching interfaces, Listener Adapter API, and the IIS Worker Process Framework API can likewise be leveraged.

For more information about the IIS7 development APIs, see Internet Information Services 7.0 SDK.

IIS7 Architecture

In addition to providing better security and performance, the new modular IIS7 architecture also provides more uniform access to resources and better extensibility. This architecture separates the core IIS Web server (responsible for accepting, pre-processing, and responding to HTTP requests) from extension modules that provide services and perform detailed processing. In previous versions of IIS, the functionality of standard modules was a part of the monolithic core server. As depicted in the following diagram, the core server engine is hosted inside a server worker process, which is started by WAS and managed by the World Wide Web Publishing Service (W3SVC). The core server then listens for incoming HTTP requests via the kernel mode listener driver, Http.sys.

The core server engine contains a unified processing pipeline that processes all incoming requests or messages for hosted native or managed application types (for example, traditional Web, ASP.NET, and Windows Communication Foundation). This pipeline was modeled after the ASP.NET 1.1 pipeline architecture. It provides a rich state machine and extensibility model for hosting external, pluggable server components, known as modules, which provide server request processing functionality and customized server behavior (for example, authentication, caching, and response generation). Modules that service requests for specific resource types are termed handlers. The following diagram shows this relationship:

A typical Web application is a URL namespace that enables a collection of services provided by one of more of these modules, together with the appropriate configuration and supporting resources.

Administrators and developers can control which modules are loaded during the initialization phase by editing the following configuration sections:

• <globalModules>—this server-level section contains the list of modules loaded by the server worker process, and the associated native DLLs that implement their functionality.

• <modules>—this application-level section contains the list of modules enabled for a particular application. This section serves to select the subset of loaded modules that should be active in an application, and also to load additional application level modules.

• <handlers>—this URL-level section contains the handler mappings that the server uses to map incoming requests to a particular module that will process it. This section is similar to the IIS6 scriptmaps or ASP.NET <httpHandlers>.

Run-Time Event Architecture

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.

Deterministic Event	Description
(Post)BeginRequest	The first step of request processing. Modules should perform any required initialization.
(Post)AuthenticateRequest	Establish the identity of the user.
(Post)AuthorizeRequest	Verify that the user has proper rights to requested resources.
(Post)ResolveRequestCache	Attempt to service request from local caches. If the attempt is successful, typically a response is immediately sent and processing jumps to the log request stage.
(Post)MapRequestHandler	Optionally, reassign the handler module that will service the current request. The core engine initially assigns this mapping.
(Post)AcquireRequestState	Acquire any necessary state for this request, such as session state or user profile.
(Post)PreExecuteRequestHandler	Perform any additional work before the handler executes.
(Post)ExecuteRequestHandler	Execute the handler that was mapped for this request.
(Post)ReleaseRequestState	Modules should save their current state data.
(Post)UpdateRequestCache	Modules should optionally update their caches to store responses that will be used to serve subsequent requests.
(Post)LogRequest	Log the request to persistent store.
(Post)EndRequest	Last step of request processing. Modules should perform any required cleanup.

Non-Deterministic Event	Description
(Post)ReadEntity	Occurs when the request entity body is being read in.
(Post)MapPath	Occurs when the virtual path in the requested URL is being mapped to a physical path on the server.
(Post)SendResponse	Occurs when the response is being sent to Http.sys.
CustomRequestNotification	Occurs when a custom notification has been triggered. Custom events can be used to implement extended announcement or provider functionality (for example, to implement a customized publish or subscribe event mechanism within extension modules). This event does not have an associated post event.

Global events do not have an associated post event.

Global Event	Description
Initialize	The server is initializing. This is the first notification the module should receive after registration.
StopListening	Termination Phase 1: the server is preparing to shut down, and the module should prepare for termination.
CacheCleanup	Termination Phase 2: the server is shutting down, and the module should release all references to shared state.
Terminate	Termination Phase 3: the server is shutting down, and the module should deallocate all state and be ready to unload.
CacheOperation	A cache operation is being performed. Modules that implement caches can register for this event to support caching of particular data types.
HealthCheck	A health check has been triggered. Modules can check their state and report whether or not the associated worker process is healthy.
ConfigurationChange	A configuration change has been detected. Modules can persist the current configuration state.
FileChange	A file change has been detected. Modules can refresh the in-memory state, if appropriate.
PreBeginRequest	A request has been received, but server processing has not started. It is useful for doing very early request filtering or rewriting.
ApplicationStart	An application is being started for the first time.
ResolveApplicationModules	A virtual application module that participated in delayed registration needs to be registered.
ApplicationStop	An application is stopping.
RSCAQuery	The server run-time state is being queried via RSCA.
TraceEvent	A trace event is being generated.
CustomNotification	A custom notification has been requested by a module.

See Also

Concepts

IIS Manager

IIS Modules

Other Resources

IIS.net

Internet Information Services 7.0 SDK

BillS' IIS Blog