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:
- MetaBase.xml is the actual XML file that contains IIS configuration settings.
- MBSchema.xml is the schema that defines the XML elements of MetaBase.xml and enforces their data types.
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
IIsComputerand so on. This is the way the metabase actually appears as you read through the XML.
A location hierarchy, starting with
/LMand 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.
Pages: 1, 2