[This is preliminary documentation and subject to change]
Editing the MetaBase.xml file directly, using common plain text tools such as Notepad, is an efficient way for administrators a way to make changes to the metabase configuration over low bandwidth connections. Editing MetaBase.xml with Notepad is more efficient because using the IIS snap-in is relatively slow over small bandwidth lines such as a 56k modem. Additionally, editing the metabase file directly is faster than using User Interface (UI) interfaces such as the IIS snap-in when hundreds or thousands of sites are running on the same computer. Editing MetaBase.xml directly is particularly helpful to administrators that that don't use programmatic methods to administer IIS, but want an alternative to the UI methods.
Changes can be made to the MetaBase.xml file while IIS is running only if Edit while running has been enabled. Otherwise changes made to MetaBase.xml can only be made when IIS is not running. Because MetaBase.xml is human editable, catastrophic format errors and recoverable metabase schema errors can be introduced by administrators. Catastrophic format errors occur when text editing yields non-well-formed XML such as missing XML tags. IIS will fail to start with Catastrophic format errors. Recoverable metabase schema errors occur when text editing yields well-formed XML but one or more properties is invalid according the metabase schema.
The metabase is Unicode. To support international and non-ASCII characters, the MetaBase.xml file supports UTF-8 encoding.
Properties with the secure attribute set will be stored as
encrypted.
MetaBase.xml is case sensitive.
The KeyType property found at a node will be used to determine the
element or node type applied to the metabase path.
Nodes that do not contain a KeyType property will be stored as the
generic object IISWebConfig, which can contain any property, and
any node can be contained within any other node.
Customer properties will be allowed for any node type.
The IISGlobal node should not be edited.
Properties which appear in schema that violate the schema (e.g.
misspelled property name) will be logged and the property will be
ignored
Custom properties require a metabase ID attribute.
The Multi-SZ attribute is replaced with the multi-string value.
Flags contain bitmask identifiers.
Reasons for using custom properties:
To use properties that are not defined in schema
To use properties with different attribute values than were defined
in schema
When writing a property using different attribute values than
what is defined in schema must be written as custom property. Only
the attributes that are different from schema must be defined in
MetaBase.xml.
Example:
In schema property
AccessFlags = AccessWrite
Custom Property
<Custom>
Name="AccessFlags"
Value=AccessRead"
</Custom>