The IIS 7.0 Configuration System and the IIS 6.0 Metabase

3/12/2011 5:30:32 PM
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
FeatureIIS 6.0 Metabase.xmlIIS 7.0 Configuration SystemWhy This Matters
Delegated configurationNot possible—all configuration is centrally stored and requires Administrative privileges to changeEnables both administrator-controlled configuration in applicationHost.config and delegated configuration in web.config filesAdministrators can delegate configuration tasks to application owners; applications can be xcopy-deployed with all of their configuration
Structural organizationProperties are not groupedProvides a hierarchy of section groups, sections, elements, and subelementsEasy 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 valuesUses multi-sz key types and bit masks to handle multiple element values such as NT AuthenticationProvidersUses collections with simple add/remove/clear syntax based on .NET Framework configuration syntax and usageEasier to read, edit, and query settings that can have multiple values
Memory vs. file-based configurationMetabase is a memory construct that is written to Metabase.xml; synchronization issues can occurConfiguration is file-based; configuration writes are persisted directly to the configuration filesIIS configuration is always fully represented in .config files
Schema extensibiltyDifficult to extend for use with custom apps; inhibits innovation from the communityBased on IIS_Schema.xml; schema easily extended with XML snippetsEnables 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.


You can find documentation that describes how IIS 6.0 metabase properties map to the new IIS 7.0 configuration schema at

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.

Figure 1. Installing IIS 6.0 Metabase Compatibility with Server Manager.

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=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

However, ASP.NET 1.1 does not include this special configuration declaration because ASP.NET was released long before IIS 7.0 development began. Therefore, you may need to manually add this section declaration for <system.webServer> and other custom IIS 7.0 sections/section groups so that you can use them in web.config files.
Video tutorials
- How To Install Windows 8

- How To Install Windows Server 2012

- How To Install Windows Server 2012 On VirtualBox

- How To Disable Windows 8 Metro UI

- How To Install Windows Store Apps From Windows 8 Classic Desktop

- How To Disable Windows Update in Windows 8

- How To Disable Windows 8 Metro UI

- How To Add Widgets To Windows 8 Lock Screen

- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010
programming4us programming4us