Introduction to IIS 7 Architecture
Written by Reagan Templin (SERGEANT)
Updated on Wednesday, April 18, 2007
Introduction
Internet Information Services (IIS) 7.0 provides a new request-processing architecture
that includes:



A new service, Windows Process Activation Service (WAS), which enables sites
to use protocols other than HTTP and HTTPS.
A Web server engine that can be customized by adding or removing modules.
A new approach to processing requests, integrating the request-processing
pipelines from IIS and ASP.NET.
This article describes the components, modules, and request-processing architecture in
the following sections.
IIS 7.0 Components
IIS 7.0 contains several components that perform important functions for the application
and Web server roles in Windows Server™ Code Name "Longhorn". Each component
has responsibilities, such as listening for requests made to the server, managing
processes, and reading configuration files. These components include protocol listeners,
such as HTTP.sys, and services, such as World Wide Web Publishing Service (WWW
service) and Windows Process Activation Service (WAS).
Protocol Listeners
Protocol listeners receive protocol-specific requests, send them to IIS for processing, and
then return responses to requestors. For example, when a client browser requests a Web
page from the Internet, the HTTP listener, HTTP.sys, picks up the request and sends it to
IIS for processing. Once IIS processes the request, HTTP.sys returns a response to the
client browser.
By default, IIS 7.0 provides HTTP.sys as the protocol listener that listens for HTTP and
HTTPS requests. HTTP.sys was introduced in IIS 6.0 as an HTTP-specific protocol
listener for HTTP requests. HTTP.sys remains the HTTP listener in IIS 7.0, but includes
support for Secure Sockets Layer (SSL).
To support services and applications that use protocols other than HTTP and HTTPS, you
can use technologies such as Windows Communication Foundation (WCF). WCF has
listener adapters that provide the functionality of both a protocol listener and a listener
adapter. Listener adapters are covered later in this document. For more information about
WCF, see Windows Communication Foundation on MSDN.
Hypertext Transfer Protocol Stack (HTTP.sys)
The HTTP listener is part of the networking subsystem of Windows operating systems,
and it is implemented as a kernel-mode device driver called the HTTP protocol stack
(HTTP.sys). HTTP.sys listens for HTTP requests from the network, passes the requests
onto IIS for processing, and then returns processed responses to client browsers.
In IIS 6.0, HTTP.sys replaced Windows Sockets API (Winsock), which was a user-mode
component used by previous versions of IIS to receive HTTP requests and send HTTP
responses. IIS 7.0 continues to rely on HTTP.sys for HTTP requests.
HTTP.sys provides the following benefits:



Kernel-mode caching. Requests for cached responses are served without
switching to user mode.
Kernel-mode request queuing. Requests cause less overhead in context switching
because the kernel forwards requests directly to the correct worker process. If no
worker process is available to accept a request, the kernel-mode request queue
holds the request until a worker process picks it up.
Request pre-processing and security filtering.
World Wide Web Publishing Service (WWW service)
In IIS 7.0, functionality that was previously handled by the World Wide Web Publishing
Service (WWW Service) alone is now split between two services: WWW Service and a
new service, Windows Process Activation Service (WAS). These two services run as
LocalSystem in the same Svchost.exe process, and share the same binaries.
Note You may also see the WWW Service referred to as W3SVC in
documentation.
How WWW Service works in IIS 6.0
In IIS 6.0, WWW Service manages the following main areas in IIS:



HTTP administration and configuration
Process management
Performance monitoring
HTTP Administration and Configuration
WWW Service reads configuration information from the IIS metabase and uses that
information to configure and update the HTTP listener, HTTP.sys. In addition, WWW
service starts, stops monitors, and manages worker processes that process HTTP requests.
Performance Monitoring
WWW Service monitors performance and provides performance counters for Web sites
and for the IIS cache.
Process Management
WWW Service manages application pools and worker processes, such as starting,
stopping, and recycling worker processes. Additionally, WWW Service monitors health
of the worker processes, and invokes rapid fail detection to stop new processes from
starting when several worker processes fail in a configurable amount of time.
How WWW Service works in IIS 7.0
In IIS 7.0, WWW service no longer manages worker processes. Instead, WWW Service
is the listener adapter for the HTTP listener, HTTP.sys. As the listener adapter, WWW
Service is primarily responsible for configuring HTTP.sys, updating HTTP.sys when
configuration changes, and notifying WAS when a request enters the request queue.
Additionally, WWW Service continues to collect the counters for Web sites. Because
performance counters remain part of the WWW Service, they are HTTP specific and do
not apply to WAS.
Windows Process Activation Service (WAS)
In IIS 7.0, Windows Process Activation Service (WAS) manages application pool
configuration and worker processes instead of WWW Service. This enables you to use
the same configuration and process model for HTTP and non-HTTP sites.
Additionally, you can run WAS without WWW Service if you do not need HTTP
functionality. For example, you can manage a Web service through a WCF listener
adapter, such as NetTcpActivator, without running the WWW Service if you do not need
to listen for HTTP requests in HTTP.sys. For information about WCF listener adapters
and hosting WCF applications in IIS 7.0 by using WAS, see Hosting in WCF on MSDN.
Configuration Management in WAS
On startup, WAS reads certain information from the ApplicationHost.config file, and
passes that information to listener adapters on the server. Listener adapters are
components that establish communication between WAS and protocol listeners, such as
HTTP.sys. Once listener adapters receive configuration information, they configure their
related protocol listeners and prepare the listeners to listen for requests.
In the case of WCF, a listener adapter includes the functionality of a protocol listener. So,
a WCF listener adapter, such as NetTcpActivator, is configured based on information
from WAS. Once NetTcpActivator is configured, it listens for requests that use the
net.tcp protocol. For more information about WCF listener adapters, see WAS Activation
Architecture on MSDN.
The following list describes the type of information that WAS reads from configuration:





Global configuration information
Protocol configuration information for both HTTP and non-HTTP protocols
Application pool configuration, such as the process account information
Site configuration, such as bindings and applications
Application configuration, such as the enabled protocols and the application pools
to which the applications belong
If ApplicationHost.config changes, WAS receives a notification and updates the listener
adapters with the new information.
Process Management
WAS manages application pools and worker processes for both HTTP and non-HTTP
requests. When a protocol listener picks up a client request, WAS determines if a worker
process is running or not. If an application pool already has a worker process servicing
requests, the listener adapter passes the request onto the worker process for processing. If
there is no worker process in the application pool, WAS will start a worker process so
that the listener adapter can pass the request to it for processing.
Note Because WAS manages processes for both HTTP and non-HTTP
protocols, you can run applications with different protocols in the same
application pool. For example, you can develop an application, such as an XML
service, and host it over both HTTP and net.tcp.
IIS 7.0 Modules
IIS 7.0 provides a new architecture that is different from previous versions of IIS. Instead
of keeping the majority of functionality within the server itself, IIS 7.0 includes a Web
server engine in which you can add or remove components, called modules, depending
on your needs.
Modules are individual features that the server uses to process requests. For example, IIS
uses authentication modules to authenticate client credentials, and cache modules to
manage cache activity.
The new architecture provides the following advantages over previous versions of IIS:



You can control which modules you want on the server.
You can customize a server to a specific role in your environment.
You can use custom modules to replace existing modules or introduce new
features.
The IIS 7.0 architecture also improves security and eases administration. By removing
unnecessary modules, you reduce the server's attack surface and memory footprint, which
is the amount of memory that server worker processes use on the machine. You also
eliminate the need to manage features that are unnecessary for your sites and
applications.
Native Modules
The following sections describe the native modules that are available with a full
installation of IIS 7.0. You can remove them or replace them with custom modules,
depending on your needs.
HTTP Modules
Several modules in IIS 7.0 perform tasks specific to Hypertext Transfer Protocol (HTTP)
in the request-processing pipeline. HTTP modules include modules to respond to
information and inquiries sent in client headers, to return HTTP errors, to redirect
requests, and more.
Module Name
Description
Sends default and configured HTTP error
CustomErrorModule
messages when an error status code is set
on a response.
Supports configurable redirection for
HttpRedirectionModule
HTTP requests.
Performs protocol-related actions, such as
ProtocolSupportModule setting response headers and redirecting
headers based on configuration.
Resource
Inetsrv\Custerr.dll
Inetsrv\Redirect.dll
Inetsrv\Protsup.dll
Security Modules
Several modules in IIS 7.0 perform tasks related to security in the request-processing
pipeline. In addition, there are separate modules for each of the authentication schemes,
which enable you to select modules for the types of authentication you want on your
server. There are also modules that perform URL authorization, and a module that filters
requests.
Module Name
Description
Performs
Anonymous
authentication
AnonymousAuthenticationModule
when no other
authentication
method succeeds.
Performs Basic
BasicAuthenticationModule
authentication.
Performs
Certificate
Mapping
CertificateMappingAuthenticationModule
authentication
using Active
Directory.
Performs Digest
DigestAuthenticationModule
authentication.
Performs
Certificate
Mapping
IISCertificateMappingAuthenticationModule authentication
using IIS
certificate
configuration.
Performs
URLScan tasks
such as configuring
allowed verbs and
RequestFilteringModule
file extensions,
setting limits, and
scanning for bad
character
sequences.
Performs URL
UrlAuthorizationModule
authorization.
Performs NTLM
WindowsAuthenticationModule
integrated
authentication.
Restricts IPv4
addresses listed in
IpRestrictionModule
the ipSecurity list
in configuration.
Resource
Inetsrv\Authanon.dll
Inetsrv\Authbas.dll
Inetsrv\Authcert.dll
Inetsrv\Authmd5.dll
Inetsrv\Authmap.dll
Inetsrv\Modrqflt.dll
Inetsrv\Urlauthz.dll
Inetsrv\Authsspi.dll
Inetsrv\iprestr.dll
Content Modules
Several modules in IIS 7.0 perform tasks related to content in the request-processing
pipeline. Content modules include modules to process requests for static files, to return a
default page when a client doesn't specify a resource in a request, to list the contents of a
directory, and more.
Module Name
Description
Executes Common Gateway Interface
CgiModule
(CGI) processes to build response
output.
Attempts to return a default document
DefaultDocumentModule for requests made to the parent
directory.
DirectoryListingModule
Lists the contents of a directory.
IsapiModule
Hosts ISAPI extension DLLs.
IsapiFilterModule
Supports ISAPI filter DLLs.
ServerSideIncludeModule Processes server-side includes code.
StaticFileModule
Serves static files.
Supports FastCGI, which provides a
FastCgiModule
high-performance alternative to CGI.
Resource
Inetsrv\Cgi.dll
Inetsrv\Defdoc.dll
Inetsrv\dirlist.dll
Inetsrv\Isapi.dll
Inetsrv\Filter.dll
Inetsrv\Iis_ssi.dll
Inetsrv\Static.dll
Inetsrv\iisfcgi.dll
Compression Modules
Two modules in IIS 7.0 perform compression in the request-processing pipeline.
Module Name
Description
Compresses responses and applies
DynamicCompressionModule Gzip compression transfer coding
to responses.
Performs pre-compression of
StaticCompressionModule
static content.
Resource
Inetsrv\Compdyn.dll
Inetsrv\Compstat.dll
Caching Modules
Several modules in IIS 7.0 perform tasks related to caching in the request-processing
pipeline. Caching improves performance of your Web sites and Web applications by
storing processed information, such as Web pages, in memory on the server, and then
reusing that information in subsequent requests for the same resource.
Module Name
Description
Provides user mode caching for files and
FileCacheModule
file handles.
HTTPCacheModule Provides kernel mode and user mode
Resource
Inetsrv\Cachfile.dll
Inetsrv\Cachhttp.dll
caching in HTTP.sys.
Provides user mode caching of user name
TokenCacheModule and token pairs for modules that produce
Windows user principals.
Provides user mode caching of URL
UriCacheModule
information.
Inetsrv\Cachtokn.dll
Inetsrv\Cachuri.dll
Logging and Diagnostics Modules
Several modules in IIS 7.0 perform tasks related to logging and diagnostics in the
request-processing pipeline. The logging modules support loading of custom modules
and passing information to HTTP.sys. The diagnostics modules follow and report events
during request processing.
Module Name
CustomLoggingModule
Description
Loads custom logging modules.
Supports the Failed Request
FailedRequestsTracingModule
Tracing feature.
Passes information and processing
HttpLoggingModule
status to HTTP.sys for logging.
Tracks requests currently executing
in worker processes and reports
RequestMonitorModule
information with Runtime Status
and Control Application
Programming Interface (RSCA).
Reports events to Microsoft Event
TracingModule
Tracing for Windows (ETW).
Resource
Inetsrv\Logcust.dll
Inetsrv\Iisfreb.dll
Inetsrv\Loghttp.dll
Inetsrv\Iisreqs.dll
Inetsrv\Iisetw.dll
Managed Support Modules
A couple of modules in IIS 7.0 support managed integration in the IIS request-processing
pipeline.
Module Name
ManagedEngine
Descriptio
n
Provides
integration
of
managed
code
modules in
the IIS
requestprocessing
pipeline.
Resource
Microsoft.NET\Framework\v2.0.50727\webe
ngine.dll
ConfigurationValidationM
odule
Validates
configurati
on issues,
such as
when an
application
is running
in
Integrated
mode but
has
handlers or
modules
declared in
the
system.we
b section.
Inetsrv\validcfg.dll
Managed Modules
In addition to native modules, IIS 7.0 enables you to use managed code modules to
extend IIS functionality. Some of the managed modules, such as UrlAuthorization, have a
native module counterpart that provides a native alternative to the managed module.
Note Managed modules depend on the ManagedEngine module.
The following table lists the managed modules that are available with a full installation of
IIS 7.0.For more information about the managed modules, see the .NET Framework SDK
2.0 on MSDN.
Module Name
AnonymousIdentificat
ion
DefaultAuthentication
Description
Manages
anonymous
identifiers,
which are
used by
features that
support
anonymous
identificatio
n such as
ASP.NET
profile.
Ensures that
an
Resource
System.Web.Security.AnonymousIdentification
Module
System.Web.Security.DefaultAuthenticationMod
ule
FileAuthorization
FormsAuthentication
OutputCache
Profile
RoleManager
Session
authenticatio
n object is
present in
the context.
Verifies that
a user has
permission
to access the
requested
file.
Supports
authenticatio
n by using
Forms
authenticatio
n.
Supports
output
caching.
Manages
user profiles
by using
ASP.NET
profile,
which stores
and retrieves
user settings
in a data
source such
as a
database.
Manages a
RolePrincipa
l instance for
the current
user.
Supports
maintaining
session state,
which
enables
storage of
data specific
to a single
client within
an
System.Web.Security.FileAuthorizationModule
System.Web.Security.FormsAuthenticationModu
le
System.Web.Caching.OutputCacheModule
System.Web.Profile.ProfileModule
System.Web.Security.RoleManagerModule
System.Web.SessionState.SessionStateModule
UrlAuthorization
UrlMappingsModule
WindowsAuthenticati
on
application
on the
server.
Determines
whether the
current user
is permitted
access to the
requested
URL, based
on the user
name or the
list of roles
that a user is
a member
of.
Supports
mapping a
real URL to
a more userfriendly
URL.
Sets the
identity of
the user for
an ASP.NET
application
when
Windows
authenticatio
n is enabled.
System.Web.Security.UrlAuthorizationModule
System.Web.UrlMappingsModule
System.Web.Security.WindowsAuthenticationM
odule
IIS 7.0 Request Processing
In IIS 7.0, the IIS and ASP.NET request pipelines combine to process requests with an
integrated approach. The new request-processing architecture consists of an ordered list
of native and managed modules that perform specific tasks in response to requests.
This design provides several benefits over previous versions of IIS. First, all file types
can use features that were originally available only to managed code. For example, you
can now use ASP.NET Forms authentication and Uniform Resource Locator (URL)
authorization for static files, Active Server Pages (ASP) files, and all other file types in
your sites and applications.
Second, this design eliminates the duplication of several features in IIS and ASP.NET.
For example, when a client requests a managed file, the server calls the appropriate
authentication module in the integrated pipeline to authenticate the client. In previous
versions of IIS, this same request would go through an authentication process in both the
IIS pipeline and in the ASP.NET pipeline.
Third, you can manage all of the modules in one location, instead of managing some
features in IIS and some in the ASP.NET configuration. This simplifies the
administration of sites and applications on the server.
IIS 7.0 Application Pools
Application pools separate applications by process boundaries to prevent an application
from affecting another application on the server. In IIS 7.0, application pools continue to
use IIS 6.0 worker process isolation mode. In addition, you can now specify a setting that
determines how to process requests that involve managed resources: Integrated mode or
Classic mode.
Note In IIS 6.0, worker process isolation mode and IIS 5.0 isolation mode are set
at the server level. This makes it impossible to run both isolation modes on the
same server. However, in IIS 7.0, Integrated mode and Classic mode are set at the
application pool level, which enables you to run applications simultaneously in
application pools with different process modes on the same server.
Integrated application pool mode
When an application pool is in Integrated mode, you can take advantage of the integrated
request-processing architecture of IIS and ASP.NET. When a worker process in an
application pool receives a request, the request passes through an ordered list of events.
Each event calls the necessary native and managed modules to process portions of the
request and to generate the response.
There are several benefits to running application pools in Integrated mode. First the
request-processing models of IIS and ASP.NET are integrated into a unified process
model. This model eliminates steps that were previously duplicated in IIS and ASP.NET,
such as authentication. Additionally, Integrated mode enables the availability of managed
features to all content types.
Classic application pool mode
When an application pool is in Classic mode, IIS 7.0 handles requests as in IIS 6.0
worker process isolation mode. ASP.NET requests first go through native processing
steps in IIS and are then routed to Aspnet_isapi.dll for processing of managed code in the
managed runtime. Finally, the request is routed back through IIS to send the response.
This separation of the IIS and ASP.NET request-processing models results in duplication
of some processing steps, such as authentication and authorization. Additionally,
managed code features, such as forms authentication, are only available to ASP.NET
applications or applications for which you have script mapped all requests to be handled
by aspnet_isapi.dll.
Be sure to test your existing applications for compatibility in Integrated mode before
upgrading a production environment to IIS 7.0 and assigning applications to application
pools in Integrated mode. You should only add an application to an application pool in
Classic mode if the application fails to work in Integrated mode. For example, your
application might rely on an authentication token passed from IIS to the managed
runtime, and, due to the new architecture in IIS 7.0, the process breaks your application.
HTTP Request Processing in IIS 7.0
IIS 7.0 has a similar HTTP request-processing flow as IIS 6.0. The diagrams in this
section provide an overview of an HTTP request in process.
The following list describes the request-processing flow that is shown in figure 1:
1. When a client browser initiates an HTTP request for a resource on the Web
server, HTTP.sys intercepts the request.
2. HTTP.sys contacts WAS to obtain information from the configuration store.
3. WAS requests configuration information from the configuration store,
applicationHost.config.
4. WWW Service receives configuration information, such as application pool and
site configuration.
5. WWW Service uses the configuration information to configure HTTP.sys.
6. WAS starts a worker process for the application pool to which the request was
made.
7. The worker process processes the request and returns a response to HTTP.sys.
8. The client receives a response.
Figure 1: Overview of an HTTP Request
In a worker process, an HTTP request passes through several ordered steps, called events,
in the Web Server Core. At each event, a native module processes part of the request,
such as authenticating the user or adding information to the event log. If a request
requires a managed module, the native ManagedEngine module creates an AppDomain,
where the managed module can perform the necessary processing, such as authenticating
a user with Forms authentication. When the request passes through all of the events in the
Web Server Core, the response is returned to HTTP.sys. Figure 2, below, shows an HTTP
request entering the worker process.
Figure 2: Detail of a HTTP request inside the Worker Process