Inside the XML Metabase of IIS 6by 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.
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. 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.
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"> <MBProperty> <IIS_Global Location ="." BINSchemaTimeStamp="80c5de04ca57c401" ChangeNumber="635" HistoryMajorVersionNumber="26" SessionKey="49634b62980000004c0...8bc121" XMLSchemaTimeStamp="e046fa04ca57c401" > </IIS_Global> <Location ="/" AdminACL="49634462f0000000a4000...419891" > </IIS_ROOT> <IIsComputer Location ="/LM" EnableEditWhileRunning="1" EnableHistory="1" MaxBandwidth="4294967295" MaxHistoryFiles="10" > </IIsComputer>
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" AppIsolated="2" AppPoolId="DefaultAppPool" AppRoot="/LM/W3SVC/1/ROOT" Path="c:\inetpub\wwwroot" > </IIsWebVirtualDir>
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:
A key structure, starting with
IIsComputer and so on. This is the way the metabase actually appears as you read through the XML.
A location hierarchy, starting with
/LM and so on. This is the way metabase properties are organized from an inheritance point of view, with directories inheriting properties of sites, which inherit properties of services, which inherit properties of servers.
Specifically, here's what the key structure typically looks like (actual structure varies with services installed and sites/directories created):
IIS_Global IIS_ROOT IIsComputer IIsConfigObject IIsConfigObject... IIsLogModules IIsCustomLogModule IIsCustomLogModule... IIsLogModule IIsLogModule... IIsMimeMap IIsWebService IIsWebServer IIsFilters IIsCertMapper IIsWebVirtualDir IIsWebServer IIsFilters IIsWebVirtualDir IIsApplicationPools IIsApplicationPool IIsFilters IIsFilter IIsCompressionScheme IIsCompressionSchemes IIsWebInfo IIsConfigObject IIsWebServer IIsWebVirtualDir IIsWebServer IIsWebVirtualDir
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:
<configuration> <MBProperty> <element attribute...></element> <element attribute...></element> <element attribute...></element> ... </MBProperty> </configuration>
<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 /LM/IISADMIN /LM/IISADMIN/EXTENSIONS /LM/IISADMIN/EXTENSIONS/DCOMCLSIDS /LM/IISADMIN/PROPERTYREGISTRATION /LM/Logging /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/MimeMap /LM/W3SVC /LM/W3SVC/1 /LM/W3SVC/1/Filters /LM/W3SVC/1/IIsCertMapper /LM/W3SVC/1/ROOT /LM/W3SVC/388907640 /LM/W3SVC/388907640/filters /LM/W3SVC/388907640/root /LM/W3SVC/AppPools /LM/W3SVC/AppPools/DefaultAppPool /LM/W3SVC/Filters /LM/W3SVC/Filters/Compression /LM/W3SVC/Filters/Compression/deflate /LM/W3SVC/Filters/Compression/gzip /LM/W3SVC/Filters/Compression/Parameters /LM/W3SVC/Info /LM/W3SVC/Info/Templates /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 </MBProperty> </configuration>
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
Now that you have a bird's-eye view of the metabase, here are some helpful resources to help you learn more.
My book, IIS 6 Administration, has a chapter on the metabase that goes into even greater detail than this article does, explaining its structure and function. The book also covers basic metabase administration tasks such as backing up and exporting the metabase using IIS Manager and scripts, restoring previous versions of the metabase from history files, and examples of metabase properties you can tweak for improved performance.
The Metabase Property Reference on Microsoft's web site summarizes the syntax and function of each and every property in the IIS 6 metabase.
Mitch Tulloch is the author of Windows 2000 Administration in a Nutshell, Windows Server 2003 in a Nutshell, and Windows Server Hacks.
Return to WindowsDevCenter.com.
Copyright © 2009 O'Reilly Media, Inc.