Working with the Metabase (IIS 6.

0)
The metabase is a hierarchical store of configuration information and schema that are used to
configure Internet Information Services (IIS) 6.0. Read this section for an overview of the
metabase structure and terminology, as well as detailed information about effectively managing
the IIS 6.0 metabase by using the graphical user interface (GUI)–based and command-line
utilities that are available with IIS 6.0.

Editing the Metabase (IIS 6.0)

Editing the MetaBase.xml file directly by using common text-editing tools is an efficient way to
configure the metabase over low-bandwidth connections. Editing MetaBase.xml with Notepad is
more efficient than using IIS Manager, because IIS Manager is relatively slow over low-
bandwidth lines, such as a 56 KB modem. Additionally, editing the metabase file directly is
faster than through user interfaces (UIs), such as IIS Manager, when hundreds or thousands of
sites are running on the same computer. Editing the MetaBase.xml file directly is particularly
useful for administrators who do not want to use programmatic methods to administer IIS but
want an alternative to the UI methods. Editing the Metabase directly over a remote connection
is not recommended because a dropped connection can leave the Metabase in an indeterminate
state.
You can make changes to the MetaBase.xml file while IIS is running only if the edit-while-
running feature is enabled. If edit-while-running is not enabled, you must stop IIS before you
edit the MetaBase.xml file. This is inefficient and not a recommended practice.

Editing the MetaBase.xml File While IIS Is Running (IIS 6.0)

This section contains information about the metabase edit-while-running feature, which is also
known as Direct Metabase Edit. The ability to edit the metabase while IIS is running makes
administration simpler and avoids site down time, because you do not have to stop IIS when
you need to change the metabase configuration.

The Edit-While-Running Process (IIS 6.0)

IIS uses Windows file change notification to determine when the MetaBase.xml file has been
saved. When IIS detects that the metabase configuration file has been saved, a series of checks
are made, as illustrated in Figure 4.3. Several possible scenarios are presented, based on the
results of the steps shown in the illustration, to demonstrate the behavior of edit-while-running.
Important
The MBSchema.xml file cannot be edited directly by using edit-while-running. Changes made to
metabase schema must be made programmatically.
Figure 4.3 The Edit-While-Running Process

Explanation of the Edit-While-Running Process

Step 1: IIS receives a file change notification that MetaBase.xml has been saved.
IIS receives a file change notification from Windows when the metabase configuration file is
saved. If MetaBase.xml is write-locked and you attempt to save MetaBase.xml directly with an
application such as Notepad, an error is generated and a file change notification does not occur.
Step 2: IIS looks in MetaBase.xml for the HistoryMajorVersionNumber value.
IIS reads the value of the HistoryMajorVersionNumber property in MetaBase.xml to
determine the major version number.
Step 3: IIS looks in the History folder for the corresponding history file.
The corresponding history file is named with the highest minor version number with the same
HistoryMajorVersionNumber value found in MetaBase.xml in step 2. If the corresponding history
file is found, IIS proceeds to step 4.
Step 4: Parse MetaBase.xml.
IIS parses MetaBase.xml to determine whether there are fatal XML errors, such as missing XML
end tags. If MetaBase.xml can be parsed successfully, IIS proceeds to step 5.
Step 5: Compare MetaBase.xml to the corresponding history file.
IIS compares MetaBase.xml to the corresponding history file of the same major version within
the History folder. IIS determines the differences between the two files and does one of the
following:
If no changes were made to MetaBase.xml, a history file is not created and no further action
•
is taken.
• If changes were made to MetaBase.xml, IIS proceeds to step 6.
Step 6: Check that the level exists in the in-memory metabase that changes were
made to in MetaBase.xml.
IIS determines whether the level/node exists within the in-memory metabase that changes
were made to in the MetaBase.xml file. If the level/key exists within the in-memory metabase,
IIS proceeds to step 7.
Step 7: Write the changes to the in-memory metabase through ABO.
The changes are written to the in-memory metabase through ABOs.
A change that was made to MetaBase.xml might not be sent to the in-memory metabase for
any of the following reasons:

• The change violates metabase schema; for example, a property name is misspelled.
The in-memory metabase is write-locked by someone making a simultaneous change by
•
using ADSI, ABO, or WMI to modify the same metabase node or property.
The key in the in-memory metabase that changes were made to in MetaBase.xml does not
•
exist. This could occur if an administrator deletes the key in the in-memory metabase, by
using a programmatic interface or IIS Manager, before MetaBase.xml is changed and saved
to disk.
If a change is not written to the in-memory metabase for any of the reasons listed above, an
error or warning is sent to the event log.
Step 8: IIS creates a new history file that contains the contents of the
corresponding history file and the changes that were written to the in-memory
metabase.
A history file is created in the History folder. This new file includes the combination of contents
of the corresponding history file plus the changes that were written to the in-memory metabase
in step 7. The new history file is named with the major version number that was found within
MetaBase.xml (the value of the HistoryMajorVersionNumber property that was determined in
step 2) and the next highest minor version number. IIS looks within the History folder to find
the highest minor version number that was used for the same major version number, and it
uses the next sequential minor version number to name the new history file. This naming
convention permits succeeding edits to the same major version of the file to work correctly.

Simultaneous Updates (IIS 6.0)

IIS supports simultaneous updates between programmatic interfaces such as ADSI and WMI.
However, under some circumstances, errors can occur as described in step 7 above. The rule is
that the last write always wins.
IIS does not support simultaneous updates between the programmatic interfaces and an
administrator who directly edits MetaBase.xml. Simultaneous writes to the same metabase node
or property can result in an error because of the resulting race condition. You can protect
against this type of error by allowing only one administrator to edit the metabase at a time.

Enabling Edit-While-Running in IIS 6.0 (IIS 6.0)

Enabling metabase edit-while-running requires that the metabase history feature is enabled and
set to a value of at least 10. The second procedure below requires IIS to be restarted.
Restarting IIS stops all sites for a short time. To enable direct metabase edit without
interruption of service, use the first procedure below.
Important You must be a member of the Administrators group on the local computer to
perform the following procedure or procedures. As a security best practice, log on to your
computer by using an account that is not in the Administrators group, and then use
the runas command to run IIS Manager as an administrator. At a command prompt,
type runas /user:Administrative_AccountName "mmc %systemroot
%\system32\inetsrv\iis.msc".

Procedures
To enable metabase edit-while-running using IIS Manager
1. In IIS Manager, right-click the local computer, and then click Properties.
2. Select the Enable Direct Metabase Edit check box.
Important
You must be a member of the Administrators group on the local computer to run scripts and
executables. As a security best practice, log on to your computer by using an account that is not
in the Administrators group, and then use the runas command to run your script or executable
as an administrator. At a command prompt, type runas /profile
/user:MyComputer\Administratorcmd to open a command window with administrator rights
and then type cscript.exeScriptName (include the script's full path and any known
parameters).

To enable metabase edit-while-running from the command line

1. From the Start menu, click Run.
2. In the Open box, type cmd, and click OK.
3. At the command prompt, type iisreset /stop, and press ENTER. Leave the command
window open.
Open the MetaBase.xml file with a plain text editor. By default, the MetaBase.xml file is located
in the systemroot\system32\inetsrv directory.
Important
All text within MetaBase.xml is case sensitive.
1. In the IIsComputer node, change the value of the EnableEditWhileRunning property
from 0 (FALSE) to 1 (TRUE). The change should look as follows:
<IIsComputer Location ="/LM"
EnableEditWhileRunning="1"
EnableHistory="1"
 MaxBandwidth="4294967295"
MaxHistoryFiles="10">
2. Save changes to the MetaBase.xml file.
3. At the command prompt, type iisreset /start, and press ENTER.

Writing the In-Memory Metabase and Schema to Disk (IIS

6.0)
The metabase is written to disk either when MetaBase.xml is edited directly and manually saved
to disk, or when the in-memory metabase is saved to disk.
Important
MetaBase.xml can be edited by hand and saved to disk only when edit-while-running is enabled
or when the IIS Admin service is stopped before the MetaBase.xml file is edited and saved.
The in-memory metabase is written to disk only under the following circumstances:
When the IIS Admin service is stopped, and there are changes pending in the in-memory
•
metabase.
The in-memory metabase is written to disk 60 seconds after a change is made to the
•
metabase; however, if more than 30 changes occur during those 60 seconds, the write-to-
disk event is postponed for another 60 seconds. The in-memory metabase write-to-disk event
is postponed a maximum of five times, after which it is written to disk.
• When saved programmatically, as when using a resource such as ADSI, WMI, or ABO.
Figure 4.4 and the following discussion describe how the in-memory metabase is written to disk.
The verification checks can influence how IIS saves the in-memory metabase to disk, as
illustrated by the possible scenarios.