So far, we’ve been discussing in some detail the
contents and mechanics of the configuration system, but we should back
up a bit and discuss applicationHost.config itself rather than its
contents.
Differences Between the IIS 7.0 Configuration System and the IIS 6.0 Metabase
The IIS 6.0
configuration store is Metabase.xml and is stored in
%windir%\system32\inetsrv. For IIS 7.0, Metabase.xml is transformed into
applicationHost.config located in %windir%\system32\inetsrv\config.
Why did the IIS team
invest such time and effort in a wholesale change to the structure and
mechanics of the configuration system? Primarily to make a quantum leap
in performance, scale, and manageability. The IIS 6.0 configuration
system is based on a system conceived and implemented with IIS 4.0 that
was part of Windows NT. It was time to rebuild with a new set of design
criteria.
The resulting system is
quite a bit more complex because it is very ambitious. Yet at the same
time, it is more manageable, scalable, and flexible. Table 1 compares some of the key differences between the IIS 6.0 metabase and the IIS 7.0 configuration files.
Table 1. Metabase.xml Comparison to IIS 7.0 Configuration System
| Feature | IIS 6.0 Metabase.xml | IIS 7.0 Configuration System | Why This Matters |
|---|
| Delegated configuration | Not possible—all configuration is centrally stored and requires Administrative privileges to change | Enables both administrator-controlled configuration in applicationHost.config and delegated configuration in web.config files | Administrators
can delegate configuration tasks to application owners; applications
can be xcopy-deployed with all of their configuration |
| Structural organization | Properties are not grouped | Provides a hierarchy of section groups, sections, elements, and subelements | Easy
to read, search, and manage; enables use of shorter element name
because each item is logically grouped in a section rather than in a
flat listing |
| Simplified description of properties with multiple values | Uses multi-sz key types and bit masks to handle multiple element values such as NT AuthenticationProviders | Uses collections with simple add/remove/clear syntax based on .NET Framework configuration syntax and usage | Easier to read, edit, and query settings that can have multiple values |
| Memory vs. file-based configuration | Metabase is a memory construct that is written to Metabase.xml; synchronization issues can occur | Configuration is file-based; configuration writes are persisted directly to the configuration files | IIS configuration is always fully represented in .config files |
| Schema extensibilty | Difficult to extend for use with custom apps; inhibits innovation from the community | Based on IIS_Schema.xml; schema easily extended with XML snippets | Enables application developers to easily integrate application settings into IIS 7.0 |
IIS 6.0 Metabase Compatibility
Despite
the complete overhaul of the configuration system, IIS 7.0 continues to
maintain backward compatibility with existing configuration scripts and
tools that target the metabase for configuring the server.
This is accomplished
by providing a metabase emulation layer that enables the metabase APIs,
exposed through the Active Base Objects (ABO) interfaces on which all
other metabase tools and scripting APIs are based. The metabase
emulation layer, called the ABO Mapper, provides immediate translation
of the metabase configuration structure and actions triggered by callers
to the new configuration system. This maps all writes and reads to the
metabase to the corresponding IIS 7.0 configuration.
This service
performance is transparent to the caller so that the existing
installers, configuration scripts, and tools continue to work as if they
were working on IIS 6.0. The ABO Mapper makes a best-effort attempt to
map all IIS 6.0 metabase properties to the corresponding IIS 7.0
configuration properties that have a known mapping. In the end,
virtually all metabase properties can be successfully mapped to the IIS
7.0 configuration, with rare exceptions.
Metabase compatibility
is not enabled by default, and you don’t need it if you are not running
any legacy IIS 6.0 configuration scripts or using third-party
installers that require ABO. If you are, though, you will need to
install the IIS 6.0 Metabase Compatibility component from the
IIS/Metabase Compatibility category in the Turn Windows Features On And
Off page of Control Panel\Programs And Features on Windows Vista, or the
IIS role in the Server Manager tool on Windows Server 2008, as shown in
Figure 1.
You
can also chose to install the legacy IIS 6.0 configuration scripts from
the IIS 6.0 Metabase Compatibility category, which provides scripts
such as adsutil.vbs and iisweb.vbs. However, we recommend that for your
configuration scripts and programs, you start to use the new
configuration tools and APIs that the IIS 7.0 configuration system
provides.
IIS 7.0 and the .NET Configuration Systems
The .NET configuration files
on IIS 7.0 (machine.config, root web.config, and application web.config)
behave exactly the same as they do on IIS 6.0. In fact, the .NET
configuration system isn’t really aware it’s running on IIS 7.0 and does
not read any of the IIS 7.0 configuration settings. However, IIS 7.0 is
very aware of .NET. The IIS 7.0 configuration hierarchy includes the
server-level .NET configuration files, machine.config and root
web.config (in addition to applicationHost.config), but the .NET
configuration system does not include IIS configuration stored in
applicationHost.config.
One of the
primary benefits of this design is that IIS 7.0 configuration settings
can be stored in the same distributed web.config configuration files as
the ASP.NET configuration settings. This enables applications to contain
all of the configuration they need to run on the IIS platform in the
web.config file, and it also enables simple xcopy deployment.
From
a developer perspective, it also enables managed modules developed for
IIS 7.0 to access .NET configuration by using IIS 7.0
Microsoft.Web.Administration and other .NET classes in the same way they
can access IIS 7.0 configuration sections. Likewise, the IIS 7.0
configuration APIs can be used to manage the .NET configuration sections
in automated deployment and management scenarios.
In addition, the IIS
Manager tool exposes a number of ASP.NET configuration features. For
example, you can configure database connection strings in the IIS
Manager instead of having to open up the .config file. IIS Manager also
enables you to manage users and roles by using the .NET role and
membership providers. This is very useful for managing user information
for features such as forms authentication and storing IIS Manager users.
The unification of the
.NET and IIS 7.0 configuration hierarchies does pose a few issues that
stem from the fact that the two configuration systems have completely
separate implementations, yet they work with the same configuration
hierarchy and configuration sections. The fact that the ASP.NET
configuration system does not read IIS 7.0 configuration sections
eliminates a lot of potential problems with the differences in behavior.
However, some problems do still exist.
One of the key
limitations stems from the difference in encryption support between the
two configuration systems. The .NET configuration files may contain user
names and passwords that the developer can encrypt. This way, when you
view the .config file, you see an encrypted secret rather than plain
text. The problem arises because IIS 7.0 and the .NET configuration
system use different methods for encrypting secrets. The .NET
configuration system supports section-level encryption, which encrypts
the entire contents of the configuration section. The IIS 7.0
configuration system supports only attribute-level encryption, which
encrypts specific attributes. Because of this, if you attempt to read an
encrypted ASP.NET configuration section through the IIS 7.0
configuration system or any of the APIs that use it, you will receive an
error. For example, this will happen if you encrypt any of the
configuration sections that the IIS Manager uses to administer ASP.NET
functionality. Likewise, you cannot encrypt ASP.NET configuration
sections with IIS 7.0 configuration encryption because ASP.NET will fail
to read their contents. For more details on this issue and how to solve
it.
Another limitation stems from the lack of a versioning mechanism for
the .NET configuration schema files provided by the IIS 7.0
configuration system. As of this writing, the IIS 7.0 configuration
system provides schema files only for the .NET Framework 2.0
configuration, and therefore IIS 7.0 might experience problems when
writing configuration to configuration files for .NET Framework 1.1 or
future versions of the .NET Framework. Moreover, some of the tools in
the IIS 7.0 configuration stack, including Appcmd.exe, can’t write to
.NET Framework configuration files for versions other then 2.0. Future
versions of IIS may address this problem.
The use of IIS 7.0
configuration in ASP.NET web.config files may also create a problem for
ASP.NET applications that are using .NET Framework 1.1. This is because
the ASP.NET configuration system is not aware of the IIS 7.0
configuration sections located in the <system.webServer>
section group (or any custom configuration sections you create using
the IIS 7.0 section extensibility mechanism), and the configuration
system will generate an error when it encounters these sections in
web.config files. ASP.NET 2.0 includes a special configuration
declaration in machine.config that maps <system.webServer> to a
special configuration section handler type that ignores the sections
when they are found.
<section name="system.webServer" type="System.Configuration.IgnoreSection,
System.Configuration, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
