[This is preliminary documentation and subject to change]
The purpose of the metabase schema is to define the default attributes of metabase properties and flags, and enforce which nodes within the metabase configuration that properties and flags can be written. Properties that are written to the metabase configuration that adhere to the rules of the metabase schema are said to be written in-schema. To write a property or flag value to the metabase configuration that is not defined in the metabase schema must be written as a custom property. For more information about writing properties to the metabase configuration, see Writing Changes to MetaBase.XML.
The metabase schema is stored in an XML formatted text file
called MBSchema.XML and written into the in-memory metabase when
IIS is started or re-started. By default the MBSchema.XML file is
found in the %windir%\system32\inetsrv folder. A
binary file called MBSchema_00000000h.bin is created when IIS is
started or restarted and the MBSchema.XML file has changed. The
sole purpose of the binary schema file is to enable faster IIS
startup times. The MBSchema_00000000h.bin file is a compiled
version of the MBSchema.XML file, and should not be modified or
deleted by administrators. For more information about the
MBSchema_00000000h.bin file, see Starting IIS.
MBSchema.XML is an XML formatted text file with a hierarchical structure of collections, properties, and flags. A collection is simply a hierarchical location within the schema that contain properties. Properties are configuration objects that are associated with IIS Admin Objects and their corresponding ABO objects. All properties contain attributes, and some properties also contain flags. Flags are identified by ABO by their unique bit mask identifier.
Collections are defined within MBSchema.XML using <Collection> tags. A collection is written in the following format:
<Collection InternalName ="CollectionName"
AttributeName="AttributeValue">
</Collection>
where CollectionName is the name of the collection, AttributeName is the name of a collection attribute, and AttributeValue is the value of the collection attribute.
The top level collection is called MetabaseBaseClass and is used to set global settings that all of the other collections inherit from.
Snippet of the MetabaseBaseClass collection:<Collection InternalName ="MetabaseBaseClass"
MetaFlagsEx="NOTABLESCHEMAHEAPENTRY" MetaFlags="HIDDEN">
<Property InternalName ="Location" Type="WSTR"
MetaFlags="PRIMARYKEY"/>
</Collection>
The collection directly following MetabaseBaseClass is called
IISConfigObject. All metabase properties that can be written to the
metabase are defined within the IisConfigObject collection. The
default values of attributes and flags for each property are
defined within this class for each property. Note: Only a few
properties contain flags.
Snippet of the IIsConfigObject collection
<Collection InternalName ="IIsConfigObject"
MetaFlagsEx="NOTABLESCHEMAHEAPENTRY" MetaFlags="HASUNKNOWNSIZES |
HIDDEN">
<Property InternalName ="KeyType"
Type="STRING"
UserType="IIS_MD_UT_SERVER"
Attributes="NO_ATTRIBUTES"
MetaFlags="PRIMARYKEY"
MetaFlagsEx="CACHE_PROPERTY_MODIFIED"
DefaultValue=""/>
.
.
</Collection>
Remaining Collections
All remaining collections directly follow the IISConfigObject
collection and define at which locations in the metabase
configuration that each property can be written. Properties are
written within these collections in the following format:
<Property InheritsPropertiesFrom
="IIsConfigObject:PropertyName"/>
where PropertyName is the name of the
property.
Note that all properties written within these remaining
collections inherit their attribute values from the IIsConfigObject
collection because the IIsConfigObject collection is where all
property attributes and flags are defined.
IIS does not allow ADSI or WMI to make updates to the metabase configuration that are not defined in the metabase schema. Changes to the metabase configuration that do not comply with the metabase schema rules, and are written directly to the MetaBase.XML file may not get written to the in-memory metabase or history file, and an error or warning is sent to the event log.