772 Chapter 14 • The Extensible Core Server
Summary
IIS 7.0 now offers developers a better environment. It’s easier than ever to extend IIS using either
native or managed code. Access to a unifi ed request pipeline now puts managed code in parity with
its native brethren. IIS now ships with over 40 modules built-in for developers to take advantage of.
Extending IIS 7.0 with native modules is remarkably less stressful. No longer are native code
developers dealing with the complexities of creating ISAPI fi lters and extensions. They now are
able to make use of the same APIs that Microsoft used in creating IIS 7.0. Deployment of native
modules is also easier. They can be placed anywhere on the server that they are running on.
Developers and administrators also have the choice of how they want to deploy these modules.
Deployments can be done from the AppCmd.exe command line utility, the IIS Manager, or by
editing the applicationsHost.confi g fi le.
There are more options for developers using managed code. Managed modules can run in two
different modes under IIS 7.0. Integrated mode provides the new features such as the unifi ed request
pipeline that both native and manage code share. Managed code has full access to all content not just
that of ASP.NET. This available for managed modules through webengine.dll, a native global module
that acts as a shim so that managed code can have direct access to the pipeline.
Developers who have applications that rely on the old IIS 6.0 architecture can do so by setting
their application pools to run in classic mode. This provides the same pipeline behaviors and the
limitations that come with IIS 6.0. It also provides a stable and secure environment to work in.
In IIS 7.0, Microsoft has created a much friendlier environment for developers and
administrators alike.
Solutions Fast Track
Understanding Development Advantages in IIS 7.0
˛ IIS 7.0 offers a new landscape for developers never before available in IIS.
˛
In constructing IIS 7.0, Microsoft ensured that core processing of requests was removed
from features that were implemented in individual modules.
˛
Access to early pipeline events, such as authenticating requests, were never possible for
managed code developers until IIS 7.0.

˛
IIS 7.0 is easier to extend than ever before for developers.
˛
Because of the unifi ed pipeline, managed code is no longer treated as a second-class citizen.
Extending IIS 7.0 with Native Modules
˛ Extending IIS with C or C++ no longer requires the creation of ISAPI extensions.
˛
Native code developers now have access to the same set of APIs that Microsoft used in
developing IIS 7.0
˛
Deployment of native modules is easier because of tools such as AppCmd.exe and IIS
Manager, or they can be done manually by editing the applicationHost.confi g fi le.
The Extensible Core Server • Chapter 14 773
Enabling Managed Code in IIS 7.0
˛ ASP.NET has access to all content types.
˛
Application pools can run in one of two modes: Integrated or Classic.
˛
Integrated mode takes advantage of the new features and capabilities of IIS 7.0.
˛
Managed code running under integrated mode makes use of a native module called
webengine.dll, which provides direct access to the unifi ed pipeline.
˛
Classic mode provides the same environment of IIS 6.0 with all the stability and security
that developers used for their legacy applications.
774 Chapter 14 • The Extensible Core Server
Frequently Asked Questions
Q: If managed code now has the same direct access to the request pipeline as native code, then why
would you create native modules?
A: Performance for one. Native code will always run faster with less overhead than managed code.

Second, managed modules are application-specifi c, where as if you need to create a global
module, then you must do so in native code.
Q: Which method is best when deploying native modules (AppCmd.exe, IIS Manager,
or manually)
?
A: It depends. If you are deploying multiple native modules at one time, then creating a script that
makes use of AppCmd.exe might be your best bet. IIS Manager is an excellent choice for those
who prefer a more task-oriented way of doing things. A person might deploy a native module
manually if they are comfortable editing confi guration fi les and feel using either method
mentioned earlier would slow them down.
Q: If I run my managed code module in classic mode, would I need to deploy webengine.dll in the
applicationHost.confi g fi le?
A: No. Only if you choose to run your code in Integrated Mode would you need webengine.dll. It
allows managed modules direct access to the request pipeline.
Q: I have some applications that must run in classic mode, but I want to create newer applications
that take advantage of the changes in IIS 7.0. Can I have some application pools running in
classic mode and others in integrated mode on the same box?
A: Yes. When you add your application pool, choose which mode you want. In IIS Manager you
will see the coexistence of integrated and classic mode pools.
Q: Why can’t I have a managed module in the <globalModules> section of the applicationHost.
confi g fi le?
A: Only native modules can reside in the <globalModules> section. Managed modules can only be
set at the application level, not the global level.
775
Chapter 15
Solutions in this chapter:
■
Introducing ApplicationHost.confi g
■
Enabling Delegated Administration in IIS 7.0

˛
Summary
˛ Solutions Fast Track
˛ Frequently Asked Questions
Get Started with IIS
7.0’s Confi guration
776 Chapter 15 • Get Started with IIS 7.0’s Confi guration
Introduction
Since IIS 4.0, administrators have grown to love the metabase, whereas developers did quite the
opposite. The metabase offered a complex, ID-based system, with tight security. In fact, to have write
access to the metabase required that a user account have administrative privileges on the Web server.
In IIS 7.0, out with the old (metabase) and in with the new (applicationHost.confi g, web.confi g) was
the order of the day. IIS 7.0 built on the successful and highly popular .confi g infrastructure ASP.
NET used to build the next-generation Web server confi guration. The major items introduced to this
XML confi guration were the System.WebServer and the System.ApplicationHost namespaces
designed to give administrators and developers a multitude of access points to confi guration. IIS 7.0
also enables system administrators (Windows administrators) to delegate sections of the confi guration
to nonadministrators easing the burden of management on themselves. Beyond that, Web farm
synchronization has never been easier than it is with IIS 7.0’s distributed confi guration capabilities.
Introducing ApplicationHost.confi g
The metabase lived a long, strong, and good life. It wasn’t until security, and developer
productivity, came to the forefront that the metabase’s shortcomings were exposed. The metabase
was not architected in a manner that offered an easy, yet productive mechanism to delegate write
capabilities to nonadministrator users. Furthermore, it offered undesirable child behavior not enabled
at the parent level by copying the entire parent metadata to the child—potentially doubling the size
of the metabase. With the new confi guration, called ApplicationHost.confi g, IIS 7.0 natively supports
the IIS 6.0 confi guration while also supporting these new robust features such as distributed
confi guration, as well as delegated confi guration.
It is important that we outline in this section the prevalent pieces of the new confi guration,
including System.WebServer and System.ApplicationHost. The latter is unable to be edited by anyone

other than system administrators (Windows), whereas the former can be unlocked and edited as part
of the application deployment process. We will focus on offering good clarifi cation between <sites>,
<globalModules>, and other ApplicationHost-enabled features.
For years the metabase has served the world of IIS well, but as the saying goes, “the only
constant in life is change,” and change is exactly what IIS 7.0 offers. The old metabase was not
designed in a way that was easy to read, and it did not provided a mechanism for delegating control
to nonadministrators. The ApplicationHost.confi g fi le has now replaced the metabase as the primary
store for IIS confi guration and settings. It has defi nitions for locking down most IIS sections to the
global level so that by default they are not overridden by lower level web.confi g fi les. The
ApplicationHost.confi g fi le is an XML fi le that resides in the %windir%\ system32\ inetsrv\ confi g
directory. It stores lists of sites, applications, virtual directories, logging, caching, and so on. It also can
be viewed or modifi ed in any text editor.
The ApplicationHost.confi g fi le contains many sections. The fi rst section you come to in the
ApplicationHost.confi g fi le and one of the most important is <confi gSections>. This section registers all
IIS and Windows Activation System (WAS) sections. It contains a list of all other sections in the fi le.
Figure 15.1 shows the <confi gSections> section and the section groups of <system.applicationHost> and
<system.webServer> of the ApplicationHost.confi g fi le. Other sections to note from the
ApplicationHost.confi g fi le are: