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

Application Development and Diagnostics

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.

Global events do not have an associated post event.

See Also

Concepts

IIS Manager

IIS Modules

Other Resources

IIS.net

Internet Information Services 7.0 SDK

BillS' IIS Blog