Web Server (IIS) Role

Applies To: Windows Server 2008

The Windows Server® 2008 operating system delivers a unified platform for Web publishing that integrates Internet Information Services (IIS), ASP.NET, and Windows Communication Foundation. IIS version 7.0 is a major enhancement to the existing IIS Web server and plays a central role in integrating Web platform technologies.

What does IIS 7.0 do?

Key pillars of the IIS 7.0 release are:

  • Flexible extensibility model for powerful customization

  • Powerful diagnostic and troubleshooting tools

  • Delegated administration

  • Enhanced security and reduced attack surface through customization

  • True application xcopy deployment

  • Integrated Application and health management for Windows Communication Foundation (WCF) services

  • Improved administration tools

These pillars help create a unified platform so that IIS 7.0 delivers a single, consistent developer and administrator model for Web solutions.

Flexible extensibility model for powerful customization

IIS 7.0 enables developers to extend IIS to provide custom functionality in new, more powerful ways. IIS 7.0 extensibility includes an all-new core server application programming interface (API) set that allows feature modules to be developed in both native code (C/C++) and managed code (languages such as C#, and Visual Basic 2005, that use the .NET Framework).

IIS 7.0 also enables extensibility of configuration, scripting, event logging, and administration tool feature-sets, providing software developers a complete server platform on which to build Web server extensions.

Powerful diagnostic and troubleshooting tools

IIS 7.0 enables developers and IT Professionals to more easily troubleshoot errant Web sites and applications. IIS 7.0 provides a clear view of internal diagnostic information about IIS, and collects and surfaces detailed diagnostic events to aid troubleshooting problematic servers.

Delegated administration

IIS 7.0 enables those who host or administer Web sites or WCF services to delegate administrative control to developers or content owners, thus reducing cost of ownership and administrative burden for the administrator. New administration tools are provided to support these delegation capabilities.

Enhanced security and reduced attack surface through customization

You can control which features to be installed and running on your Web server. IIS 7.0 is made up of more than 40 separate feature modules. Each feature module can be independently installed on the server to reduce the attack surface of the server, and reduce administrative overhead where it is not needed. For more information about the various feature modules, see IIS 7.0 Modules (https://go.microsoft.com/fwlink/?LinkId=68740).

True application xcopy deployment

IIS 7.0 allows you to store IIS configuration settings in web.config files, which makes it much easier to use xcopy to copy applications across multiple front-end Web servers, thereby avoiding costly and error-prone replication and manual synchronization issues.

Application and health management for WCF services

To enhance the development and hosting of WCF services over many protocols, Windows Server 2008 includes 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 IIS 6.0 request processing model.

Improved administration tools

IIS 7.0 introduces a new task-oriented user interface (UI) and a new command-line tool for managing and administering Web servers, Web sites, and Web applications. For more information, see the section "Administration tools" within What existing functionality is changing? in this topic.

Who will be interested in this feature?

Any business or organization that hosts or develops Web sites or WCF services can benefit from the improvements made in IIS 7.0.

You should review this topic, and the additional supporting documentation on IIS 7.0, if you are in any of the following groups:

  • IT planners and analysts who are technically evaluating the product

  • Enterprise IT planners and designers for organizations

  • IT professionals who deploy or administer IIS

  • Developers who create Web sites or WCF services

  • Internet Service Providers (ISPs) or similar organizations that provide Web hosting

Are there any special considerations?

Windows Firewall is turned on by default

Windows Firewall is enabled by default in Windows Server 2008. During the installation of the Web Server (IIS) role, the installation process adds the following inbound Windows Firewall rules to allow traffic for the role services that you selected:

  • If you install HTTP-related and HTTPS-related role services, a rule is added to Windows Firewall to allow traffic for HTTP on port 80 and HTTPS on port 443. These rules appear in the Windows Firewall list as World Wide Web Services HTTP Traffic In and World Wide Web Services HTTPS Traffic In. They are turned on automatically.

  • If you install FTP-related role services, a rule is added to Windows Firewall to allow traffic for FTP on port 21. This rule appears in the Windows Firewall list as FTP Server Traffic In. It is turned on automatically.

  • If you install the Management Service, a rule is added to Windows Firewall to allow traffic for the service on port 8172. This rule appears in the Windows Firewall list as Web Management Service Traffic In. It must be turned on by the server administrator.

What existing functionality is changing?

Configuration

IIS 7.0 introduces some major improvements to the way configuration data is stored and accessed. One of the key goals of the IIS 7.0 release is to enable distributed configuration of IIS settings, which allows administrators to specify IIS configuration settings in files that are stored with the code and content.

Why is this change important?

Distributed configuration enables administrators to specify configuration settings for a Web site or application in the same directory as the code or content. By specifying configuration settings in a single file, distributed configuration allows administrators to delegate administration of selected features of Web sites or Web applications so others, for example, application developers, can modify those features. Administrators can also lock specific configuration settings so that they cannot be changed by anyone else.

By using distributed configuration, the configuration settings for a specific site or application can 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, where all servers retrieve configuration settings and content from a file server.

What works differently?

IIS 7.0 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 configuration settings that are accessible via a common set of APIs and stored in a consistent format. The IIS 7.0 configuration system is also fully extensible, so developers can extend the configuration store to include custom configuration with the same fidelity and priority as IIS configuration.

IIS 7.0 stores global, or computer-wide, configuration in the %windir%\system32\inetsrv directory in a file called ApplicationHost.config. In this file there are two major configuration section groups:

  • system.applicationHost

  • system.webServer

The system.applicationHost section group contains configuration for site, application, virtual directory and application pools. The system.webServer section group contains configuration for all other settings, including global Web defaults.

URL specific configuration can also be stored in ApplicationHost.config using <location> tags. IIS 7.0 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, along with ASP.NET configuration.

How do I fix issues? How should I prepare for this change?

Because Windows Server 2008 is a major release, you should expect to spend some time familiarizing yourself with the new configuration options.

Production Web sites and WCF services that currently run under IIS 6.0 should be thoroughly tested before being moved to production under IIS 7.0; although IIS 7.0 is designed to be compatible (see the section Do I need to change any existing code?)

If you are using custom IIS 6.0 command-line scripts, you might want to convert them to IIS 7.0. See the section Do I need to change any existing code? later in this topic.

Administration tools

IIS 7.0 introduces the following completely rewritten new administration tools for managing IIS:

  • Graphical user interface, IIS Manager

  • Command-line tool, appcmd.exe

  • Configuration store, based on the .NET Framework 2.0 configuration store, which supports the direct editing of settings

  • WMI provider that can read or change settings in the configuration store

  • Managed interface, Microsoft.Web.Administration, which exposes the same information exposed by the WMI provider

In addition, the IIS 6.0 MMC snap-in is also provided with Windows Server 2008 to support remote administration and to administer FTP sites.

You can install administration tools and Web server components separately.

IIS 7.0 also includes a new WMI provider which broadens scripting access to all IIS and ASP.NET configuration.

The Microsoft.Web.Administration interface provides a strongly-typed managed interface to retrieve the same data exposed by WMI scripts.

The IIS 6.0 command-line scripts have also been replaced with a new powerful command-line tool, appcmd.exe.

Why is this change important?

The new administration tools fully support the distributed configuration and delegation of administrative responsibility. The delegation can be very specific, allowing an administrator to decide exactly which functions to delegate, on a case-by-case basis.

What works differently? Are there any dependencies?

The new administration tools fully support the new IIS 7.0 distributed configuration. They also allow for delegated (non-Administrative) access to configuration for individual sites and applications. The administration tools support non-Administrator, even non-Windows credentials to authenticate to a specific site or application and manage configuration for only that scope.

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

The administration tools are fully extensible, enabling developers to build new administration modules using the .NET Framework to easily plug in new administration user interface modules that work as transparently as those that ship with IIS 7.0.

Core server

The IIS 7.0 core Web server includes some fundamental changes from IIS 6.0. For example, both native and managed code is processed through a single request pipeline. In addition, IIS 7.0 features a Web server engine in which you can add or remove components, called modules, depending on your needs.

Why is this change important?

These changes enable a significant reduction in attack surface, more extensibility, and increased support for extending IIS 7.0 core functionality by creating managed code modules. The new worker process Web core also provides access to all notification events in the request pipeline. The 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.

What works differently?

In previous versions of IIS all functionality was built in by default, and there was no easy way to extend or replace any of that functionality. However, the IIS 7.0 core is divided into over 40 separate feature modules. The core also includes a new Win32 API for building core server modules. Core server modules are new and more powerful replacements for Internet Server Application Programming Interface (ISAPI) filters and extensions, although these filters and extensions are still supported in IIS 7.0.

Because all IIS core server features were developed so that IIS 7.0 can use the new Win32 API and as discrete feature modules, you can add, remove, or even replace IIS feature modules.

IIS 7.0 also includes support for development of core Web server extensions using the .NET Framework. IIS 7.0 has integrated the existing IHttpModule API for ASP.NET, enabling your managed code modules to access all events in the request pipeline, for all requests.

How do I fix these issues?

Please see the section Do I need to change any existing code? in this topic, particularly if you are using ISAPI filters.

Diagnostics

IIS 7.0 includes two major improvements that aid in diagnostics and troubleshooting of errant Web sites and applications.

Why is this functionality important?

The diagnostics and troubleshooting changes in IIS 7.0 allow a developer or an administrator to see, in real time, requests that are running on the server. Now, it is possible to filter for error conditions that are difficult to reproduce and automatically trap the error with a detailed trace log.

What works differently?

IIS 7.0 includes a new Runtime State and Control API, which provides real-time state information about application pools, worker processes, sites, application domains, and even running requests.

This information is exposed through a native Component Object Model (COM) API. The API itself is wrapped and exposed through the new IIS WMI provider, appcmd.exe, and IIS Manager. This allows users to quickly and easily check Web server status regardless of the management environment you use.

IIS 7.0 also includes detailed trace events throughout the request and response path, allowing 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 also elapsed time and other debugging information to assist in troubleshooting all types of errors and when a system stops responding.

To enable the collection of these trace events, IIS 7.0 can be configured to automatically capture full trace logs for any given request based on elapsed time or error response codes.

Do I need to change any existing code?

IIS 7.0 is built to be compatible with existing releases. All existing ASP, ASP.NET 1.1, and ASP.NET 2.0 applications are expected to run on IIS 7.0 without any code changes (using the compatible ISAPI support).

All existing ISAPI extensions and most ISAPI filters will also continue to work, unchanged. However, ISAPI filters that rely on READ RAW DATA notification are not supported in IIS 7.0.

For existing Active Directory® Service Interfaces (ADSI) and WMI scripts, IIS 7.0 will provide feature parity with previous releases, enabling them to run directly against the new configuration store.

Is this server role available in all editions of Windows Server 2008?

IIS 7.0 is available in all editions of Windows Server. There is no difference in functionality among editions. IIS 7.0 is available on 32-bit and 64-bit platforms.

Additional references

To learn more about the Web Server role you can view the Help on your server. To do this, open IIS Manager and press F1.

For more information about the Web Server role, see topics for Windows Server 2008 on the Web: