Hack 56 Map the Metabase

Here are some helpful maps to help you navigate the complexities of the metabase .

While basic IIS configuration can be done using Internet Services Manager, sometimes you need to roll up your sleeves and look under the hood. Under IIS's hood you'll find the metabase, the key repository of IIS configuration information. The metabase contains hundreds of settings, from how a web server performs to the format used for logging visits to sites. Both Windows 2000 and Windows Server 2003 let you edit the metabase directly, but the tools you use are different because the format of the metabase is different in each platform [Hack #54].

Before you start mucking about in your metabase, you need to know your way around, because its structure is quite complex. The goal of this hack is to give you a bird's-eye view of how the metabase is organized, so you can find things more quickly and avoid making mistakes that could confuse your server.

Surprisingly enough, you won't find this information anywhere on Microsoft's web site, even though it is crucial to metabase exploration.

Once you know the lay of the land, you can start hacking the metabase [Hack #57] with a certain level of confidence.

Logical Structure

The logical structure is the easiest to consider first, because it's much the same for both IIS 5 and IIS 6. The important thing to keep in mind is that the metabase hierarchy reflects the way you manage IIS web sites, directories, and files using Internet Services Manger. For example, when you want to log visits to a site on your server, you can use Internet Services Manager to enable the Log Visits setting at the site level (for all web content on your site), at the virtual-directory level (for content stored in a single virtual directory), or at the page level (for monitoring traffic to individual pages). Most configuration settings can also be configured globally for the entire IIS machine. As a result, when you are navigating the properties sheets of Internet Services Manager, you'll see the following hierarchical progression: Server Site Directory File.

The logical structure of the metabase is organized similarly and uses a location attribute to identify where a setting lies within the hierarchy. The top of this hierarchy is called LM , which stands for Local Machine (i.e., the server itself). Each metabase key then has a location attribute that identifies where the key resides. As a simple example, the Path key located at LM/W3SVC/1/ROOT contains the string value C:\Inetpub\ wwwroot and identifies the location of the content for the Default Web Site. Figure 6-3 shows where this key is located in the IIS 5 metabase using MetaEdit, the tool used for editing the metabase on that platform. Note that the metabase is organized hierarchically, using keys in a fashion similar to the way the Windows Registry is displayed in RegEdit.

Figure 6-3. Path key for Default Web Site in the IIS 5 metabase

To understand the location LM/W3SVC/1/ROOT , let's break it down: LM is the local machine itself, W3SVC means we're looking at web sites (not FTP, SMTP, or NNTP), 1 is the site ID for the Default Web Site, and ROOT contains configuration settings (keys) that apply to all virtual directories and files within the web site. The site ID is a number generated for each web site on the server to uniquely identify the site internally.

Location map for IIS 5

Now, here is the big picture of how the IIS 5 metabase is logically organized, omitting some of the deeper levels:

 LM LM/IISADMIN LM/IISADMIN/EXTENSIONS LM/IISADMIN/PROPERTYREGISTRATION LM/Logging LM/Logging/Custom Logging 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/2 LM/W3SVC/2/filters LM/W3SVC/2/root LM/W3SVC/Filters LM/W3SVC/Info 

Not so complicated after all, is it? The main locations under LM are pretty self-explanatory. For example, IISADMIN contains configuration settings for the IISAdmin service, Logging defines the settings for the different logging formats supported by IIS, and MimeMap has a copy of the MIME mappings that define how IIS responds to client requests for files with particular extensions. Everything under W3SVC relates to the World Wide Web Publishing Services on the machine, which you can see is hosting two web sites: the Default Web Site ( site ID 1 ) and a custom web site ( site ID 2 ). If your server is running additional services, such as FTP, you'll also find locations for those within the hierarchy.

Of course, before you can successfully hack the metabase, you need to know how to find the site ID for a given web site and vice versa. In IIS 6, this is easily done. Select the Web Sites node in Internet Services Manager and look under the Identifier column in the pane on the right. This displays the site ID for each web site running on the server.

Finding the site ID under IIS 5 is a little trickier. If you want to find the site ID for a particular site, open its properties sheet in Internet Services Manager, choose the Web Site tab, and click the Properties button in the Logging section at the bottom. If you have W3C Extended Log File Format configured (the default), then the site ID is embedded in the name of the folder in which your IIS log files are saved. In our example, these folders are %SystemRoot%\System32\LogFiles\W3SVC1 for the Default Web Site and %SystemRoot%\System32\LogFiles\W3SVC2 for the custom web site. Figure 6-4 shows the Extended Logging Properties dialogue box for the custom web site.

Figure 6-4. Finding the site ID for a web site in IIS 5

Of course, if you have dozens of web sites running on your machine, this is a rather slow approach. As a workaround you can use findweb.vbs , one of the sample administrator scripts included in the Inetpub\AdminSamples folder on IIS 5. Drop to a command prompt and type cscript findweb.vbs sitename , where sitename is the descriptive name of your site in Internet Services Manager. Be sure to use quotes if there are spaces in the site name. The output of the script will include the web site numberanother name for the site ID. For more information about using scripts to administer IIS, see [Hack #59].

What about the reverse? Given a site ID within the metabase, how do you find the descriptive name of the web site as displayed in Internet Services Manager? One way is to use MetaEdit to view the contents of the ServerComment key in the location LM\W3SVC\ n , where n is the site ID for the web site. The data value for this key is the descriptive name of the site in Internet Services Manager.

Location map for IIS 6

IIS 6 is logically organized similarly to IIS 5, but with a few differences:

 . / /LM /LM/IISADMIN /LM/IISADMIN/EXTENSIONS /LM/IISADMIN/PROPERTYREGISTRATION /LM/Logging /LM/Logging/Custom Logging /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/Info 

Here, we see that LM is the third level instead of the root. The root level (.) contains keys for versioning (timestamp and change number) and history major version number [Hack #54]. The next level ( / ) contains an AdminACL key used for protecting the metabase against unauthorized modification. Beyond that, everything under LM is pretty much the same as in IIS 5, with the obvious exception of /LM/W3SVC/AppPools and locations beneath it, which contain information about application pools when IIS 6 is running in worker process isolation mode.

Another thing to notice is that the site ID for the custom web site is 388097640 instead of 2 . While IIS 5 assigns site IDs to new web sites serially ( 1 , 2 , and so on), IIS 6 assigns what looks like a random number as a web site's site ID. Actually, it's not random at all; it's a pseudorandom number derived from scrambling the descriptive name of the web site. So, if you have two web servers, each with a custom site named My Company Site , they'll both be assigned the same site ID in IIS 6. The reason for doing it this way is to ensure that web farms with multiple IIS machines that host copies of sites have identical site IDs for mirrored sites. If you prefer, you can disable this feature via the Registry Editor; simply add a new REG_DWORD value to the HKLM\SOFTWARE\Microsoft\InetMgr\Parameters key, give the new value the name IncrementalSiteIDCreation , and assign it a value of 1 . Restart IIS to jog the change into effect. This might be useful in a service provider environment, for example, if you have several IIS machines that host thousands of web sites and you don't want to worry about having two users create sites with the same descriptive name.

Finally, be aware that while the basic logical structure of the metabase is almost identical in IIS 5 and IIS 6, there are many new metabase keys in IIS 6 that have no counterpart in IIS 5. Also, some IIS 5 keys have been retired or renamed in IIS 6. A full discussion of these items is obviously beyond the scope of this book; thankfully, I have another for you which does discuss this stuff at length: IIS 6 Administration (Osborne/McGraw-Hill).

Physical Structure

On IIS 5, the physical structure of the metabase is hidden within the proprietary format of the binary metabase.bin file, so you need to know only the logical structure (location of keys) to find your way around the metabase using MetaEdit. Things are different in IIS 6, however, because here the metabase is a plain text file ( MetaBase.xml ) that is formatted in XML and adheres to strict constraints laid down by the schema ( MBScehma.xml ). In the XML syntax for the metabase, the location of a key is given by its location attribute within the XML tag for the key. For example, the Path key previously discussed for the Default Web Site in IIS 5 looks like this in the IIS 6 metabase:

 <IIsWebVirtualDir Location = "/LM/W3SVC/1/ROOT"        Path = "c:\inetpub\wwwroot"    > </IisWebVirtualDir> 

If you know a little XML, you can see that IIsWebVirtualDir is an element whose attributes include Location and Path , contained within a pair of opening and closing tags. To be accurate, IIsWebVirtualDir is itself a property called KeyType , and I've left out some other attributes to make the basic structure clear. Anyway, by editing this section of the MetaBase.xml file directly, using a text editor such as Notepad, you can easily change the default path for the home directory of the Default Web Site.

XML map for IIS 6

So, now let's see the big picture of what the IIS 6 metabase looks like in terms of XML tags instead of location. This is important to know, because while the location map described earlier really defines the hierarchical structure of metabase keys, the actual physical metabase file is formatted in XML and that's what you have to look at when you edit it. Anyway, here's the XML for an IIS 6 machine configured with two web sites (keys that can be repeated are indicated with ellipses):

 <?xml version ="1.0"?> <configuration xmlns="urn:microsoft-catalog:XML_Metabase_V54_0">    <MBProperty>       IIS_Global       IIS_ROOT       IIsComputer       IIsConfigObject...               IIsLogModules               IIsCustomLogModule...       IIsLogModule...       IIsMimeMap       IIsWebService               IIsWebServer               IIsFilters               IIsCertMapper               IIsWebVirtualDir               IIsWebServer               IIsFilters               IIsWebVirtualDir               IIsApplicationPools               IIsApplicationPool               IIsFilters               IIsFilter               IisCompressionScheme...               IIsCompressionSchemes               IIsWebInfo               IIsConfigObject               IIsWebServer               IIsWebVirtualDir       IIsWebServer               IIsWebVirtualDir            </MBProperty> </configuration> 

As you can see from the duplicate sections beginning with IIsWebServer , two web sites are running on this machine. If you examine the details of these sections, you'll find they have identical KeyType attributes but different Location attributes. Also, note that unlike the location map, which accurately reflects the hierarchical structure of metabase keys, the XML map shows that the MetaBase.xml file is almost flat, with all KeyType attributes nested equally within <MBProperty> tags, which themselves are nested within global <configuration> tags.

Of course, the metabase can get much more complicated if you have additional web sites, directories, and services installed. But now that you know the basic lay of the land, you should be able to find your way about. Just don't forget to back up the metabase before you start hacking away at it!