Windows DevCenter    
 Published on Windows DevCenter (
 See this if you're having trouble printing code examples

Windows Server Hacks

Inside the XML Metabase of IIS 6

by Mitch Tulloch, author of Windows Server 2003 in a Nutshell and Windows Server Hacks

One of the under-the-hood changes in IIS 6 is that the metabase is now an XML file instead of the binary file (metabase.bin) of earlier IIS versions. This means the metabase is a plain-text file that can be edited using a simple text editor like Notepad, even while IIS is running.

Before you start hacking away at the metabase, however, you need to know your way around, and this article is designed to provide you with a bird's-eye view of how the metabase is organized. For a general overview of the changes in IIS 6 see my earlier article, Inside IIS 6.

Physical Structure

The first thing you should know is that there are actually two XML files that make up the metabase:

Both of these files are found in %SystemRoot%\System32\Inetsrv and Administrators have Full Control permission to modify them. In fact, if edit-while-running is enabled (see Figure 1) then you can even edit MetaBase.xml while IIS is running, though you're actually editing an in-memory version of this file that is then flushed to disk within 5 minutes of any changes having been made (or immediately if the changes were made programmatically using ADSI).

Figure 1
Figure 1. Enabling edit-while-running on IIS 6.

In addition to these two metabase files, IIS 6 also maintains versioned copies of these files called history files. These files are stored in %%SystemRoot%\System32\Inetsrv\History and can be used to roll back changes to the metabase when something goes wrong. IIS maintains both major and minor versions of these history files, the major version number incrementing when IIS is restarted or its configuration saved to disk and the minor version incrementing when the metabase is edited by hand using Notepad. You may also find error files in this directory too, which usually occur when editing causes metabase corruption.

Logical Structure

From a logical point of view, the structure of MetaBase.xml is that of a typical XML file with elements defined by tags (a pair of opening and closing tags defines a key). Here's a quick peek at the beginning of the metabase for a default installation of IIS (I've edited it a bit):

<?xml version ="1.0"?>
<configuration xmlns="urn:microsoft-catalog:XML_Metabase_V61_0">
<IIS_Global	Location ="."
<Location ="/"
<IIsComputer	Location ="/LM"

Note that each key like IIsComputer has an opening and closing tag, and the opening tag has various attributes like EnableEditWhileRunning that have different values. Right away you can see that IIS creates a maximum of 10 history files before overwriting the oldest. The nice thing about the XML metabase is that it's in human readable form, more or less, so it's easy to work your way through it, figuring out what each section does.

One key to navigating the metabase is understanding location attributes, which indicate where a metabase key logically resides within the hierarchy of servers, services, sites, and directories that make up IIS. For example, examine the following short piece of metabase code:

<IIsWebVirtualDir	Location ="/LM/W3SVC/1/ROOT"
		AccessFlags="AccessRead | AccessScript"
		AppFriendlyName="Default Application"

This metabase key is named IIsWebVirtualDir and its location attribute is /LM/W3SVC/1/ROOT, which we can interpret to mean the home directory (ROOT) of the Default Web Site (1) of the World Wide Web Publishing Service (W3SVC) on the local machine (LM). Each metabase key has a unique location attribute like this to identify where in the metabase hierarchy the key resides.

This means you can view the logical structure of the metabase two ways:

Specifically, here's what the key structure typically looks like (actual structure varies with services installed and sites/directories created):


Notice that the key structure is flat i.e. all metabase keys are at the same level from an XML point of view and are contained within the MBProperty key, which itself is contained within the configuration key. So from an XML point of view the structure of MetaBase.xml is simple and looks like this:

      <element attribute...></element>
      <element attribute...></element>
      <element attribute...></element>

Where each <element attribute...></element> defines a different metabase key. It's useful to grasp this structure so you can find your way around the metabase quickly when you want to edit it, but it's also important to understand the location hierarchy as well since this determines inheritance of metabase properties. So here's what the location hierarchy typically looks like:

/LM/Logging/Custom Logging
/LM/Logging/Custom Logging/Date
/LM/Logging/Custom Logging/Extended Properties
/LM/Logging/Custom Logging/Extended Properties/Bytes Received
/LM/Logging/Custom Logging/Extended Properties/Bytes Sent
/LM/Logging/Custom Logging/Extended Properties/Client IP Address
/LM/Logging/Custom Logging/Extended Properties/Cookie
/LM/Logging/Custom Logging/Extended Properties/Host
/LM/Logging/Custom Logging/Extended Properties/Method
/LM/Logging/Custom Logging/Extended Properties/Protocol Status
/LM/Logging/Custom Logging/Extended Properties/Protocol Substatus
/LM/Logging/Custom Logging/Extended Properties/Protocol Version
/LM/Logging/Custom Logging/Extended Properties/Referer
/LM/Logging/Custom Logging/Extended Properties/Server IP
/LM/Logging/Custom Logging/Extended Properties/Server Name
/LM/Logging/Custom Logging/Extended Properties/Server Port
/LM/Logging/Custom Logging/Extended Properties/Service Name
/LM/Logging/Custom Logging/Extended Properties/Time Taken
/LM/Logging/Custom Logging/Extended Properties/URI Query
/LM/Logging/Custom Logging/Extended Properties/URI Stem
/LM/Logging/Custom Logging/Extended Properties/User Agent
/LM/Logging/Custom Logging/Extended Properties/User Name
/LM/Logging/Custom Logging/Extended Properties/Win32 Status
/LM/Logging/Custom Logging/Time
/LM/Logging/Microsoft IIS Log File Format
/LM/Logging/NCSA Common Log File Format
/LM/Logging/ODBC Logging
/LM/Logging/W3C Extended Log File Format
/LM/W3SVC/Info/Templates/Public Web Site
/LM/W3SVC/Info/Templates/Public Web Site/Root
/LM/W3SVC/Info/Templates/Secure Web Site
/LM/W3SVC/Info/Templates/Secure Web Site/Root

If you're familiar with how IIS 6 works, this location hierarchy makes a lot more sense from a logical point of view than the key structure. For example, we can immediately see that the XML element with location /LM/W3SVC/388907640 contains metabase properties for a web site with ID number 388907640.


Now that you have a bird's-eye view of the metabase, here are some helpful resources to help you learn more.

Mitch Tulloch is the author of Windows 2000 Administration in a Nutshell, Windows Server 2003 in a Nutshell, and Windows Server Hacks.

Return to

Copyright © 2009 O'Reilly Media, Inc.