ࡱ > o@ n bjbj
p
p @ o o d b b b b b b b b 8 t b " ^ F F F ! \ $ B R ` Q b ; ! ! ; ; b b F F B 0 0 0 ; 0 b F b F 0 ; 0 0 u1 @ ' b b F ~2 ( g X 0 W d * h b b b b b b b , s 0 W ` b b D{ e0 " b b Chapter 4
Working with the Metabase
The metabase is a hierarchical store of configuration information and schema that are used to configure Internet Information Services (IIS)6.0. Read this chapter for an overview of the metabase structure and terminology, as well as detailed information about effectively managing the IIS6.0 metabase by using the graphical user interface (GUI)based and command-line utilities that are available with IIS6.0.
In This Chapter
TOC \h \z \t "Heading 1,1" HYPERLINK \l "_Toc63491615" Overview of the IIS6.0 Metabase PAGEREF _Toc63491615 \h 2
HYPERLINK \l "_Toc63491616" Metabase Structure PAGEREF _Toc63491616 \h 8
HYPERLINK \l "_Toc63491617" Metabase Security PAGEREF _Toc63491617 \h 15
HYPERLINK \l "_Toc63491618" Backing Up and Restoring the Metabase PAGEREF _Toc63491618 \h 19
HYPERLINK \l "_Toc63491619" Editing the Metabase PAGEREF _Toc63491619 \h 28
HYPERLINK \l "_Toc63491620" Metabase Import and Export PAGEREF _Toc63491620 \h 43
HYPERLINK \l "_Toc63491621" Additional Resources PAGEREF _Toc63491621 \h 49
Related Information
For step-by-step instructions and information to help you complete many of the tasks described in this chapter, see Common Administrative Tasksiisrg_tas_LPPR in this book.
For information about how the metabase fits into the overall architecture of IIS6.0, see IIS6.0 Architectureiisrg_arc_OVERVIEW in this book.
For information about the IIS6.0 metabase properties, see the Metabase Property Reference in IIS6.0 Help, which is accessible from IIS Manager.
Overview of the IIS6.0 Metabase
The Internet Information Services (IIS)6.0 metabase comprises two plaintext XML files that store IIS configuration values and schema. The metabase can be edited manually, by using IIS Manager, or it can be edited programmatically. In addition, the IIS6.0 metabase is extensible in a highly efficient manner as your IIS deployment grows, so does the metabase. By using an inheritance model, explicit declarations of duplicate values are avoided, which reduces overhead when IIS reads configuration values from the metabase.
The metabase is a hierarchical store of configuration information and schema that are used to configure IIS. The metabase configuration and schema for IIS4.0 and IIS5.0 were stored in a single binary file named MetaBase.bin, which was not easy to read or edit. IIS6.0 replaces MetaBase.bin with two XML files named MetaBase.xml and MBSchema.xml. These files are stored on your computer in the systemroot\System32\Inetsrv folder. Only users who are members of the Administrators group can view and modify these files.
The metabase configuration file, MetaBase.xml, stores most of the IIS configuration. Some IIS configuration values are also stored in the Windows registry. If a configuration value is one that you might need to configure or change, or if you can access the setting in the IIS6.0 user interface, then the setting is typically stored in the IIS metabase.
The MetaBase.xml file is organized in a hierarchical structure, which can vary depending on the choices that are made when IIS is installed and, if needed, reconfigured. When IIS is started or restarted, the configuration settings are read from MetaBase.xml and copied into the IIS cache in-memory, which is referred to as the in-memory metabase. When IIS Manager or programmatic interfaces are used to change IIS configuration, the changes are made to the in-memory metabase and persisted to MetaBase.xml after a previously configured number of changes, or according to regular time intervals.
In physical terms, the metabase is a combination of the MetaBase.xml and MBSchema.xml files and the in-memory metabase. The IIS configuration information is stored in the MetaBase.xml file, while the metabase schema is stored in the MBSchema.xml file. When IIS is started, these files are read by the storage layer and then written to the in-memory metabase through Admin Base Objects (ABOs), as shown in Figure4.1.
Figure4. SEQ Figure \* ARABIC 1Metabase Communication Layers
The metabase configuration and schema are stored in separate nodes in the in-memory metabase. The in-memory metabase itself resides in the IIS file cache in your computers RAM. While IIS is running, changes that are made to the in-memory metabase are periodically saved to disk. The in-memory metabase is also saved to disk when IIS is stopped.
IIS6.0 Metabase Features
The IIS6.0 metabase includes the following features:
The metabase schema can be modified by an administrator
Active Directory Service Interfaces (ADSI) and Windows Management Instrumentation (WMI) use the metabase schema to enforce which properties can be written at a particular key in the metabase. The schema also enforces the data types that can be used for a particular property attribute. You can modify the metabase schema by using ADSI or WMI to customize this enforcement, or to allow out-of -schema properties to be written in the metabase. For information about extending the metabase schema, see Extending the Metabase Schema in IIS6.0 Help, which is accessible from IIS Manager.
The metabase is 100percent compatible with IIS5.0 metabase APIs
Because the XML metabase in IIS6.0 is fully compatible with IIS5.0 metabase application programming interfaces (APIs), existing scripts and code will continue to work.
Metabase performance and scalability are improved
The IIS6.0 metabase improves performance and scalability over earlier versions of IIS in the following ways:
Comparable or better disk footprint size compared to the IIS5.0 metabase
Faster read times on Web server startup than the IIS5.0 binary metabase
Equivalent write performance to the IIS5.0 binary metabase
The metabase incorporates rich functionality
The metabase incorporates rich functionality with the following features:
Property inheritance
Data typing of property values
Change notification when metabase properties change
Security
Simplified backup and restore of your IIS configuration
Easier import and export of individual nodes to other computers
Benefits of Plaintext XML Files
Plaintext XML metabase files offer the following benefits:
Metabase files can be edited directly by using common text editors
The metabase configuration file, MetaBase.xml, can be easily read and edited by using common text editors, such as Notepad, which is provided as part of the Microsoft Windows operating system. Editing the metabase configuration file directly will be of interest primarily for administrators who do not want to use scripts or code to administer IIS. In addition, editing the metabase configuration file directly is faster than using IIS Manager when administering IIS over a slow network connection. It is recommended that you become familiar with the structure of MetaBase.xml before you attempt to configure IIS by editing the MetaBase.xml file.
Important
Editing the MBSchema.xml file directly is not supported. Changes made to the metabase schema must be made programmatically by using the IIS ADSI provider.
Improved metabase corruption recovery and troubleshooting
The metabase makes it easier to diagnose potential metabase corruption because the metabase is stored in a plaintext file, and it can be analyzed by using tools such as the WinDiff utility. The WinDiff utility is located in the Deploy.cab file in the \Support\Tools folder of your Microsoft Windows Server2003, Standard Edition; Windows Server2003, Enterprise Edition; Windows Server2003, Datacenter Edition; or Windows Server2003, Web Edition operating system CD. As the metabase is edited and saved to disk, IIS makes copies of each version of the MetaBase.xml and MBSchema.xml files in the History folder. In other words, the metabase history feature is like an automatic backup mechanism. You can use history files to compare changes that have been made to the MetaBase.xml and MBSchema.xml files.
Improved metabase backup and restore capabilities
By using Backup/Restore Configuration, administrators can back up the metabase and encrypt it with any password. If a critical failure occurs, the metabase can be restored on a different computer or on a different installation of the operating system. Additionally, the metabase can be restored by using an earlier version of the MetaBase.xml and MBSchema.xml files from the History folder.
Metabase Terminology
MetaBase.xml is structured by using keys. Keys are analogous to file folders in a file system or registry keys in the registry. Each key contains a Location attribute, which specifies its hierarchical location in the metabase. Properties, which define the values for configuring IIS, are contained in keys. Because MetaBase.xml is structured hierarchically, a particular property can be configured differently at different keys. Properties contain attributes, such as the Value attribute.
Table4.1 summarizes the metabase terminology that is used to describe the structure of the IIS metabase. These terms are discussed in more detail later in this chapter.
Table4. SEQ Table \* ARABIC 1Metabase Terminology
TermDescriptionKeyA hierarchical container in MetaBase.xml that is used to contain properties. Each key contains the Location attribute within the start tag of the key, specifying the hierarchical position of the key in MetaBase.xml. A metabase key is analogous to a file folder or registry key.LocationEach key contains a Location attribute a sequence of location names separated by one or more forward slashes (/) that uniquely identifies the hierarchical position of the key in MetaBase.xml. For example /LM is the location of the IIsComputer key, and /LM/W3SVC is the location of the IIsWebService key. The latter is a child key of the LM location. A child key is a key that is contained by another key.Property or Custom PropertyA property or custom property defines values that are used to configure IIS. Properties contain attributes; some properties, such as AccessFlags, also contain flags. Properties are contained by keys and can be written, in MetaBase.xml, as schema-defined or custom.AttributesMetabase properties contain several attributes that describe some characteristics of the property. Keys also contain attributes, such as the Location attribute or the DefaultDoc attribute found within the IIsWebService key.
Do not confuse the term attributes as used here to describe IIS metabase properties with XML attributes, which describe general XML structure.Flag A flag is a bit within the DWORD value of a property that contains flags. Each flag within a property is used to configure particular functionality of the property, such as read or write access. The sum of the flag values for a property becomes the sum of the value attribute for that property.
Keys and Locations
Metabase keys are analogous to registry keys or a directory in a file system. Each metabase key is identified by its name and location, which are defined within the start tag of the key. The following example shows two keys, IIsConfigObject and IIsLogModules, each having a unique location as defined by the value of its respective Location attribute:
Most key names are the same as the value of the KeyType property, also known as the ABO class name, which relates to the type of key. The IIsLogModules key, seen in the example above, is named this way. If you change the KeyType value of a metabase key programmatically, the name of the key changes in MetaBase.xml when the in-memory metabase is saved. This KeyType value is important because the schema-defined collection that is named by using the same KeyType enforces which properties the key can contain.
Keys named IIsConfigObject are special because they are not named by using a KeyType value. Because all properties are schema-defined in the IIsConfigObject collection, keys in MetaBase.xml that are named IIsConfigObject can contain any property. You can specify a KeyType value for a key named IIsConfigObject by writing the KeyType property in the key as a custom property. This is not a recommended method, however, because it does not work with ADSI. Preferably, use a real object, not IIsConfigObject.
Some key names describe the type of data at a unique location in the metabase, and thus might appear at multiple locations. For example, because you can have more than one virtual directory, IIsWebVirtualDir is a key that can appear at multiple locations. The Location attribute defines the hierarchical position of a key in MetaBase.xml. The value of the Location attribute, with only two exceptions, is a sequence of location names separated by one or more forward slashes (/) that uniquely identifies the hierarchical position of the key in MetaBase.xml.
The exceptions are the IIS_Global key, which has the highest hierarchical position in MetaBase.xml (Location = .), and the IIS_ROOT key, which has the next-highest hierarchical position in MetaBase.xml (Location = /). The next-highest hierarchical position is the IIsComputer key (Location = /LM). All remaining keys in MetaBase.xml are contained by the IIsComputer key; therefore, their location always begins with /LM/LocationName, where LocationName is the name of the location.
The hierarchical position of any metabase key can be determined by looking at its Location attribute. For example /LM is the location of the IIsComputer key, and /LM/W3SVC is the location of the IIsWebService key. Because the /LM/W3SVC location begins with /LM followed by a forward slash character (/) and another location name (W3SVC), the IIsWebService key at location /LM/W3SVC is a child of the IIsComputer key. A child key is a key that is contained by another key. A key that contains another key is also called a parent key.
XML Terminology Related to IIS
Because MetaBase.xml is an XML file constructed with XML elements, it helps to be familiar with XML terminology and metabase terminology to understand how MetaBase.xml is structured. Table4.2 identifies and defines the XML terms and relates them to their use in MetaBase.xml.
Table4. SEQ Table \* ARABIC 2XML Terminology and How It Relates to the IIS Metabase
TermXML DescriptionRelation to MetaBase.xmlXML declarationA processing instruction at the start of an XML document, such as , that declares the file to be XML code.The first line in MetaBase.xml is an XML declaration.ElementA logical unit of information. Elements are surrounded by and tags, where ElementName is the name of the element. Elements can contain attributes.Keys and custom properties are written by using XML elements.Root elementA single element that contains all the other elements and character data that make up an XML document; also known as a document element.MetaBase.xml contains a root element named .Start tagA tag that marks the start of an element, such as , where ElementName is the name of the element.In MetaBase.xml, start tags are used to identify the start of a key or custom property. End tagA tag that marks the end of an element, such as , where ElementName is the name of the element.In MetaBase.xml, end tags are used to identify the end of a key or custom property.Element typeIndicated by the name that occurs in its start tag and end tag.In MetaBase.xml, the element type for metabase keys is actually the value of the KeyType property. For example, IIsWebService is the KeyType that is used to identify the World Wide Web Publishing Service (WWW service) key. Custom properties use the name Custom as the element type.AttributeA name and value pair that is associated with an XML element and that provides more information about the content of that element.
Do not confuse the term attribute as used here to describe XML structure with an IIS metabase property attribute that describes an IIS property.A metabase property contains several attributes that describe the characteristics of the property, such as the data type or value. Keys also contain attributes, such as the Location attribute or the DefaultDoc attribute found within the IIsWebService key.CommentText that is not to be treated as part of the document. Comments are delimited by tags.In MetaBase.xml, comments are delimited by tags, and must be written above the key to which they pertain. If you put a comment inside an XML node, it is removed by IIS. In addition, no comments are allowed above the IIS_Global node.
Metabase Structure
The XML declaration occupies the first line in MetaBase.xml and indicates that the file is formatted as XML. The root element, named , contains all other elements.
The IIS_Global key is the highest-level key in the metabase that contains properties. Consider the IIS_Global key to be read-only; do not configure its properties.
The IIS_ROOT key (Location = /) is the highest-level key in which you can configure properties. Properties that are configured at the IIS_ROOT key affect the general operation of IIS.
The IIsComputer key (Location = /LM) contains all remaining metabase locations. Table4.3 lists, in hierarchical order, child locations that can exist within the namespace of the /LM location. The File Transfer Protocol (FTP), Network News Transfer Protocol (NNTP), and Simple Mail Transfer Protocol (SMTP) components are not installed with IIS by default. Therefore, the /LM/MSFTPSVC, /LM/NNTPSVC, and /LM/SmtpSvc locations do not exist in MetaBase.xml unless their respective components have been installed.
The Local Machine Namespace
The local machine (LM) namespace is the parent location in the hierarchical structure of keys where all services and sites are organized. These keys, each of which contains their own unique location, are organized in the following format:
/LM/Service/Site/ROOT/VirtualDirectory/Directory/File
Where the replaceable parameters are:
Service = MSFTPSVC, NNTPSVC, SmtpSvc, or W3SVC
Site = unique number identifier for the FTP, NNTP, SMTP, or Web, site
ROOT = root virtual directory of the site
VirtualDirectory = virtual directory
Directory = physical directory
File = file name
Each site is a server instance, and is referred to by the number used in its namespace. For example, /LM/W3SVC/1 specifies the location of the key that contains the first Web site, and /LM/MSFTPSVC/3 specifies the location of the key that contains the third FTP site.
Important
Beginning with IIS6.0, the default Web site is numbered 1, and when a new Web site is created, a Web site identification number is randomly generated based on the name of the Web site. You can enable sequential numbering of Web sites, which was the method of generating Web site identification numbers in IIS5.1 and earlier, by setting the IncrementalSiteIDCreation registry key to 1.
Table4.3 lists the locations of the parent keys that are contained in the LM namespace. Because their child keys are too numerous, they are not listed here.
Table4. SEQ Table \* ARABIC 3Local Machine Locations
LocationKeys at this location/LM/EventManagerKeys at the /LM/EventManager location and its child locations configure Microsoft Exchange Server. You should not configure keys at the /LM/EventManager location or its child keys by editing the MetaBase.xml file./LM/IISADMINKeys at the /LM/IISADMIN location and its child locations record DCOM extensions to IIS. Because the /LM/IISADMIN location is internally configured by IIS, you should not configure keys at /LM/IISADMIN or its child locations./LM/LoggingKeys at the /LM/Logging location and its child locations configure IIS logging./LM/MimeMapKeys at the /LM/MimeMap location configure the MimeMap property./LM/MSFTPSVCKeys at the /LM/MSFTPSVC location and its child locations configure the FTP service and sites./LM/NNTPSVCKeys at the /LM/NNTPSVC location and its child locations configure the NNTP service and sites./LM/SmtpSvcKeys at the /LM/SmtpSvc location and its child locations configure the SMTP service and sites./LM/W3SVCKeys at the /LM/W3SVC location configure properties that are global to the WWW service. /LM/W3SVC/1Keys at the /LM/W3SVC/1 location and its child locations configure properties that are specific to the first Web site./LM/W3SVC/AppPoolsKeys at the /LM/W3SVC/AppPools location configure properties that are global to all application pools. Keys at child locations, such as /LM/W3SVC/AppPools/DefaultAppPool, configure properties that are specific to a particular application pool./LM/W3SVC/FiltersKeys at the /LM/W3SVC/Filters location and its child locations configure Internet Server API (ISAPI) filters, and global compression schemes./LM/W3SVC/InfoKeys at the /LM/W3SVC/Info location configure properties that are global to all Web sites./LM/W3SVC/Info/TemplatesThe /LM/W3SVC/Info/Templates location and its child locations were used by the IIS Permissions Wizard in earlier versions of IIS. It remains solely for legacy compatibility. You should not configure keys at the /LM/W3SVC/Info/Templates location by editing the MetaBase.xml file.
Property Inheritance
Property inheritance configures IIS by using as few property settings as possible. The benefits of using a minimal number of property settings to configure IIS are as follows:
Faster IIS cache performance
Reduced memory consumption
Reduced time required for IIS administration
Metabase properties are used to provide detailed control of IIS functionality. All metabase properties contain attributes, such as the DefaultValue attribute, which specify the configuration of the properties. Most metabase properties are inheritable, and they are specified as inheritable in MBSchema.xml by using the string value INHERIT as part of the value of the Attributes attribute. The following example shows the default attributes for the HttpErrors property in MBSchema.xml:
Hierarchical Relationship of Keys
The metabase is designed so that properties can be set differently at different keys. To understand how property inheritance works, it is necessary to first understand the hierarchical relationship of keys in the MetaBase.xml file. In relation to other keys, a key can be located in MetaBase.xml at a higher level, lower level, or the same level. The Location attribute of each key determines the level in which a key exists in the hierarchical structure.
The following example illustrates the relationship between the IIsWebService, IIsWebServer, and IIsWebVirtualDir keys. The example uses indentation to illustrate the hierarchical relationship of the keys.
In this example, the IIsWebService key is the highest-level key. The IIsWebServer keys are at a lower level than IIsWebService, and the IIsWebVirtualDir keys are at a lower level than the IIsWebServer keys. Keys that are at the same level cannot inherit properties from each other. Therefore, because the IIsWebServer keys are at the same hierarchical level in the metabase, they cannot inherit properties from each other. The IIsWebVirtualDir keys are also at the same level in relation to each other, and therefore they cannot inherit properties from each other.
Note
The hierarchical structure of the metabase is determined by the Location attribute of the keys themselves, not the class name of the keys.
Inheritance
Inheritable properties that are not explicitly set at a lower-level key are automatically inherited from the key at the next-higher level in which the property is configured. The IIS_ROOT key is the highest key in MetaBase.xml from which a property can be inherited.
The following example illustrates properties that are configured differently in different keys in MetaBase.xml, as well as properties that are inherited. The names of properties that are set at a specific metabase key appear in bold text. Otherwise, the names of properties that are inherited from the next-highest key that has the inheritable property set appear in plain text. XML comments precede the property or properties to which they correspond.
DefaultDoc = "Default.htm,Default.asp,index.htm,Default.aspx"
ContentIndexed = "TRUE"
DefaultDoc = "Default.htm,Default.asp,index.htm,iisstart.htm,Default.aspx"
>
>
ContentIndexed = "TRUE"
>
The Metabase Schema
The metabase schema defines what properties can exist in the metabase configuration file. The metabase schema also enforces which properties can be set at which keys. The metabase schema provides this enforcement only for schema-defined properties, which are properties written to the metabase configuration file that adhere to the rules of metabase schema. Properties that are not schema-defined can be written in the metabase configuration file as custom properties. Custom properties can be used in the metabase configuration file to override schema enforcement or to configure a property with values other than the default values that are defined by the schema.
Collections
The metabase schema is organized into containers called collections. Collections are defined in MBSchema.xml by using start and end tags, and they are written in the following format:
.
.
In the example above, CollectionName is the name of the entire collection. MetaFlagName and its associated MetaFlagValue apply to the entire collection. PropertyName and its associated PropertyValue are individual settings within the collection. FlagName and its associated FlagValue are individual settings within a property.
All collections exist at the same hierarchical level in MBSchema.xml. Therefore, no collection is a parent of another. Reading the MBSchema.xml file from top to bottom, the first collection, named MetabaseBaseClass, defines global settings in the schema.
The following code example is taken from the metabase schema file to illustrate how collections are defined.
The collection directly below MetabaseBaseClass is named IIsConfigObject. The IIsConfigObject collection is unique, because it is where all properties are defined. Only properties that are defined in the IIsConfigObject collection can be written to the metabase configuration as schema-defined properties.
Properties
Properties are configuration objects that are associated with IIS Admin Objects and their corresponding ABOs. All properties that are defined in the IIsConfigObject collection contain attributes. The default values of these attributes for each property are also defined.
Note
The default values that are assigned to property attributes in the IIsConfigObject collection are not necessarily the values that are written to the metabase configuration when IIS is installed. The default values of attributes, which are defined by the IIsConfigObject collection, are used when you write a schema-defined property to the metabase configuration file after IIS is installed.
Each property that is defined in the IIsConfigObject collection contains the following attributes: ID, Type, UserType, Attributes, InternalName, and DefaultValue. Some properties also contain the following attributes: MetaFlags, MetaFlagsEx, StartingNumber, and EndingNumber. Property attributes are contained in the start tag. The following example from the IIsConfigObject collection illustrates how a property is defined.
Flags
In addition to attributes, some properties also contain flags. Each flag configures a unique functionality of the property, such as read or write access. Each flag is identified by the ABO that uses unique bitmask identifier of the flag.
Flags contain attributes named Value and ID. Flags are defined in the propertys start and end tags, and they are identified by using tags. The sum value of all flags that are set for a property determines the value of the propertys DefaultValue attribute, which is also called the default value of the property. The following example illustrates a property that contains flags.
Note
Flags and their attributes are written in the start and end tags of a property. A property that does not contain a flag is encapsulated in the start tag of the property, and it does not use end tags.
Remaining Collections
All remaining collections, which are below the IIsConfigObject collection, are organized by key type. These collections enforce at which keys in the metabase configuration a schema-defined property can be written. For example, if a collection named IIsWebServer contains the ServerComment property, IIS allows the ServerComment property to be written to any key in the metabase configuration that uses the IIsWebServer key type. Therefore, only properties that are contained in these remaining collections can be written (as schema-defined properties) in a metabase key of the same key type in MetaBase.xml.
The exception to this rule is the IIsConfigObject key type, described earlier. Because all properties are contained in the IIsConfigObject collection, all properties can be written to any key in the metabase configuration of the IIsConfigObject key type.
Properties are written in these remaining collections in the following format:
where PropertyName is the name of the property.
All of the properties that are contained by these remaining collections inherit their default values from the IIsConfigObject collection, because the IIsConfigObject collection is where all properties are defined.
You cannot use ADSI or WMI, which are not defined in metabase schema, to update properties in the metabase configuration. Changes written directly to the MetaBase.xml file that do not comply with metabase schema rules might not be written to the in-memory metabase. If this occurs, an error or warning is sent to the event log.
Metabase Security
A default installation of IIS6.0 ensures metabase security by setting strict access control entries (ACEs) on the metabase files and by encrypting sensitive data within the files. If you maintain this level of security, perform regular backups, use a strong administrator password, and limit the number of users who have administrative credentials, you are taking the proper precautions to protect your metabase files.
File-Level Security
As described in Table4.4, IIS installs the metabase files with strict ACEs set to prevent anyone but administrators from viewing your configuration data. An access control list (ACL) is a container for ACEs.
Table4. SEQ Table \* ARABIC 4Metabase files, purpose, and permissions
FilePurposeACLsystemroot\System32\Inetsrv\MetaBase.xmlStores configuration data for the IIS services.NT AUTHORITY\SYSTEM : Full control
BUILTIN\Administrators : Full controlsystemroot\System32\Inetsrv\MBSchema.xmlStores the schema for the configuration file. The schema defines what IIS properties can be set at certain metabase keys.NT AUTHORITY\SYSTEM : Full control
BUILTIN\Administrators : Full controlsystemroot\System32\Inetsrv\ History\HistoryFileStores the metabase history files that are created automatically by IIS.NT AUTHORITY\SYSTEM : Full control
BUILTIN\Administrators : Full controlsystemroot\System32\Inetsrv\MetaBack\BackupFileStores the metabase backup files that are created on demand by using Backup/Restore Configuration.NT AUTHORITY\SYSTEM : Full control
BUILTIN\Administrators : Full control
Encrypted Properties
IIS encrypts sensitive data in the metabase configuration file, MetaBase.xml, so that it cannot be viewed even if an unauthorized user gains access to the file.
Important
Do not manually change encrypted properties encrypted properties in MetaBase.xml. There is no way to encrypt your data before inserting it by using Notepad or another text editor. Only WMI, ADSI, or ABOs can be used to change the data in encrypted properties.
Metabase properties are marked for encryption by an attribute that is set on the property in the metabase schema file. The following example from the metabase schema file shows how the AnonymousUserPass property is marked for encryption with a SECURE attribute:
Caution
You cannot use WMI, ADSI, or ABOs to add an attribute to an existing property in the metabase schema. For example, you cannot add the SECURE attribute to an existing property. If you attempt to use WMI, ADSI, or ABOs to remove a property in the metabase schema and then create it again with the SECURE attribute, the metabase configuration data for that property is lost. You can, however, use ADSI to create new properties in the metabase schema with the SECURE attribute. Manual changes made to the metabase schema are not supported and might cause an error.
The following metabase properties are encrypted:
ADConnectionsPassword
AdminACL
AdminACLBin
AnonymousUserPass
ImapDsPassword
LogOdbcPassword
Pop3DsPassword
RoutePassword
SmtpDsPassword
UNCPassword
FeedPassword
WAMUserPass
Checklist: Metabase Security
Table4.5 is a list of recommended steps to ensure the security of the metabase.
Table4. SEQ Table \* ARABIC 5Steps to ensure metabase security
StepReferenceMake sure that the passwords for all accounts on your computer are strong and not written anywhere near the computer or within view.See Passwords in Help and Support Center for Windows Server2003.Maintain strict access control permissions on the metabase files that are listed in Table4.4. Only the LocalSystem account and the Administrators group should be listed in the ACLs as having full control of the metabase files, including the history files and backups. IIS sets this access control by default.See Access control in Help and Support Center for Windows Server2003.Employ the concept of least permission on your computer. Allow only one person to know the Administrator password, and limit the number of people whose accounts are in the Administrators group. Set ACLs on all folders and files so that the fewest users have the lowest-level permission needed to run required tasks. Set IIS security on all IIS applications and virtual directories so that the least permission necessary exists to allow proper clients to view your content.See Access control and Security in Help and Support Center for Windows Server2003.Do not run the cipher command or use Encrypting File System (EFS) on the metabase files. Sensitive data, such as passwords that are stored in MetaBase.xml, are already encrypted. Encrypting the entire MetaBase.xml file slows down your IIS server and might cause errors.See the Cipher and Encrypting File System topics in Help and Support Center for Windows Server2003.When you edit the MetaBase.xml file manually, copy the MetaBase.xml file first, and then work on the copy. When you have checked your changes, replace MetaBase.xml with your copy.See Editing the MetaBase.xml File While IIS Is Runningiisrg_met_EEWE later in this chapter.Create backups of your metabase files using Backup/Restore Configuration whenever you make a significant change in the metabase. If you allow other people to configure the metabase, make it a policy that they create a backup with their name in the title whenever they make a change. IIS periodically makes its own backup files, called history files, but history files might not be created for every change to the metabase.See Backing Up the Metabaseiisrg_met_GRNE later in this chapter.Do not use the metabase import and export feature to create regular backup files. This feature is meant to transport sections of the metabase to other computers However, it is recommended that you create an export file for your entire metabase periodically in the event that your computer hardware fails and you must move your Web sites to another computer.See Metabase Import and Exportiisrg_met_ELYA later in this chapter.Remember that backing up or exporting the metabase does not back up your content (.htm files, .asp files, components, and so on). The metabase only holds configuration data, such as where your content is stored. To back up your content, use Windows Backup.See Backing up and restoring data in Help and Support Center for Windows Server2003.Monitor your event log for IIS event messages. For example, if you attempt to make changes to the metabase when there is a write-lock on the in-memory database, a metabase history file is created and an error is written to the event log. If you successfully create an FTP virtual directory, but IIS cannot enumerate the physical directory, an error is written to the event log.See Event Viewer in Help and Support Center for Windows Server2003.Set up file auditing on the various files that affect the metabase. This way, if the metabase becomes corrupted, you can identify the account of the last user who made a change. Select your auditing choices carefully for the files listed below, and monitor the audit logs for a period of time to determine if the settings are meeting your needs.
systemroot\System32\Inetsrv\MetaBase.xml
If you choose to audit the MetaBase.xml file, only users who edit the metabase manually are identified in the audit logs by their own account name. Users who edit the metabase by using IIS Manager or other tools are logged as accessing the metabase under the LocalSystem account. Because IIS itself is constantly accessing the metabase, audit logs can grow very quickly unless you limit auditing to specific users, such as the local Administrators group, and specific access attempts, such as writing to a file. Auditing MetaBase.xml is still valuable for determining when changes were made, but you might have to audit the other files listed here to find the exact identity of the user.
Custom tools and script files that use WMI, ADSI, or ABO s to edit the metabase
Auditing should be set on these tools to identify who executes them. If you audit MetaBase.xml and want to find out who made a change at 3:01 P.M. on a certain day, you can look in the audit logs for your scripts and tools to see if someone ran one of them at 3:01 P.M.
systemroot\System32\Inetsrv\Inetmgr.exe
Audit this file for the same reason you audit custom tools and script files, above.See Auditing overview in Help and Support Center for Windows Server2003.
Backing Up and Restoring the Metabase
Creating backups of the metabase is a vital part of maintaining metabase reliability. The ability to create backup files and to restore the metabase by using backup files has been enhanced in IIS6.0. You can now restore the backup on other computers if portable backup has been chosen. History file copies of the metabase are created automatically by IIS, and an IIS administrator using IIS Manager can create them on demand. All backups, regardless of how they were created, are stored together and displayed together in IIS Manager.
Restoring a backup from an earlier version of IIS is not supported. After you install or upgrade to IIS6.0, it is recommended that you perform a metabase backup as soon as possible to preserve your configuration data.
Backing up the metabase should be supplemented with proper metabase security practices. For more information about metabase security, see Metabase Securityiisrg_met_SVLB earlier in this chapter.
Backing Up the Metabase
Using Backup/Restore Configuration, you can create complete backup copies of the IIS metabase. The backup files are either portable or non-portable copies of the metabase configuration file (MetaBase.xml) and the matching metabase schema file (MBSchema.xml). Metabase backup files provide a way to restore your metabase configuration and schema data in the event that the metabase becomes corrupted. Portable backup files can be restored either to the computer on which the backup was made or to other installations of Windows Server2003, while non-portable backup files can only be restored to the same system from which it was made.
Backup files contain only configuration data; they do not include your content. To back up your content as well, use Windows Backup. For more information about using Windows Backup, see Backing up and restoring data in Help and Support Center for Microsoft Windows Server2003.
Note
The metabase is locked while the backup is in progress.
Portable Backup
When creating a portable backup, the administrator provides a password that is used by IIS to encrypt the backup files. The password is encrypted and stored in the header of the backup file. Only the administrator password and secure properties within the backup files are encrypted; all other information within the backup files is plain text. After the backup file is encrypted, the password within the backup file cannot be changed.
Non-portable Backup
When creating a non-portable backup, the administrator does not supply a password. Therefore, non-portable backup files are encrypted with a blank password, which allows any member of the Administrators group to restore the metabase. Only the blank password and secure properties are encrypted; all other information within the backup file is plain text.
Important
You must be a member of the Administrators group on the local computer to perform the following procedure or procedures, or you must have been delegated the appropriate authority. 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.
To back up the IIS metabase
In IIS Manager, right-click the local computer, point to All Tasks, and click Backup/Restore Configuration.
Click Create Backup, and then type a name for the backup file in the Configuration backup name box. Note that the backup name is not case-sensitive.
To restore the backup to a different computer, select the Encrypt backup using password check box, type a password in the Password box, and then type the same password in the Confirm password box.
Click OK.
When a backup is created, a set of two files i s c r e a t e d a n d n a m e d i n t h e f o l l o w i n g w a y :
N a m e . m d x a n d N a m e . s c x x e " a a " \ \ i i s R G _ M E T . d o c - 1 0 7 2
I n t h e s y n t a x a b o v e , N a m e i s t h e n a m e t h a t t h e a d m i n i s t r a t o r u s e s t o n a m e t h e b a c k u p s e t , a n d x i s t h e v e r s i o n n u m b e r o f t h e b a c k u p s e t , s t a r t i n g w i t h 0 ( z e r o ) . The version number is increased by one for each backup set that uses the same name, up to 999. For example, if you use the name MyBackup as the name of your backup set twice, MyBackup.md0 and MyBackup.sc0 are created on the first backup; on the second backup, the files are named MyBackup.md1 and MyBackup.sc1. By default, backup files are stored in the systemroot\System32\Inetsrv\MetaBack folder.
The Metabase History Feature
IIS automatically maintains a record of metabase changes in history files that are saved to disk. You can also configure the number of metabase history files to save. By using the metabase history feature, you can revert the metabase through any number of changes to restore a particular configuration, or to see what has changed between revisions.
By marking each new metabase file with a unique version number and saving a copy of the file in the History folder, the metabase history feature automatically keeps track of metabase changes that are saved to disk. Each history file is then available for restoring the MetaBase.xml and MBSchema.xml files from the History folder, editing the MetaBase.xml file while IIS is running, and troubleshooting event log errors. The metabase history feature is enabled by default.
History Folder
The History folder stores versioned copies of the MetaBase.xml and MBSchema.xml files. These copies can only be viewed by members of the Administrators group. The location of the History folder is systemroot\System32\Inetsrv\History.
A history file pair consists of a MetaBase.xml and MBSchema.xml file of the same major and minor version numbers. The default setting allows for a maximum of 10 versioned history file pairs to be stored in the History folder, but you can configure this number. However, before increasing the number of versioned sets of files stored in the History folder, you should ensure that you have adequate hard disk space on the drive volume where the History folder is located. (You can estimate the amount of hard disk space that is required by multiplying the average combined file size of MetaBase.xml and MBSchema.xml files by the number of versions that you want to store in the History folder.) You should not decrease the value of the MaxHistoryFiles property to below 10.
When the in-memory metabase is written to disk, IIS checks to determine whether the number of history file pairs that are contained in the History folder exceeds the value of the MaxHistoryFiles property. If the number of history file pairs exceeds the value of the MaxHistoryFiles property, the oldest history file pair is deleted.
For information about backing up your entire operating system, including special steps that must be performed to include IIS in that backup, see Backing up and restoring data in Help and Support Center for Windows Server2003. For information about the event log, see Event log in Help and Support Center for Windows Server2003.
Configuring the Metabase History Feature
By default, the metabase history feature is enabled and the number of history file pairs that are saved within the History folder is defined by the default value of the MaxHistoryFiles property. A history file pair is the combination of a copy of a MetaBase.xml file and an MBSchema.xml file of the same version in the History folder. If the EnableHistory property is not written in the MetaBase.xml file, IIS interprets the absence of the property to mean that the history feature is enabled, and the MaxHistoryFiles property is set to the default value.
To change the metabase history default settings
Add the EnableHistory and MaxHistoryFiles metabase properties to the /LM level of the metabase.
To disable metabase history
Set the value of the EnableHistory property to 0 (zero).
To enable metabase history
Set the value of the EnableHistory property to 1.
To change the number of history files that are stored in the History folder
Change the value of the MaxHistoryFiles property.
Caution
Disabling history files can have serious consequences in the event that the metabase becomes corrupted by improper editing. Without backup files, the IIS server might have to be reconfigured from an empty state. However, keeping backup files can also be a security risk if you do not ensure that the files are protected by ACLs. By default, only members of the Administrators group can view the history files, but if you copy history files to a new location, you must duplicate those settings. For information about configuring ACLs, see Access control in Help and Support Center for Windows Server2003.
Naming the Metabase History Files
To keep track of metabase history, IIS uses the following versioning scheme to enumerate the copies of MetaBase.xml that are stored in the History folder.
Metabase Version Numbers
The value of the HistoryMajorVersionNumber metabase property, also referred to as the major version number, increases when the in-memory metabase is written to disk.
The minor version number increases when the edit-while-running feature is enabled and an administrator changes and saves the MetaBase.xml file directly with an application such as Notepad.
HistoryMajorVersionNumber Property
The HistoryMajorVersionNumber property is located under the IIS_Global node in the metabase, as shown in the following example:
Important
IIS uses the HistoryMajorVersionNumber property to track the versions of the metabase. Thus, manually changing the value of the HistoryMajorVersionNumber property is not recommended.
Minor Version Number
The minor version number is not a property that is stored in the metabase. IIS calculates the minor version number when the MetaBase.xml file is edited and saved directly, and if edit-while-running is enabled, as follows:
IIS looks in the History folder to determine the last minor version number that was used for a history file with the same HistoryMajorVersionNumber number as MetaBase.xml. IIS then uses the next sequential minor version number when naming the new history file.
When a history file is created because the in-memory metabase is written to disk, either through the regular timed history algorithm, or by the user explicitly saving the current configuration to disk, the major version number is incremented by 1, and the minor version number is reset to zero.
Naming the History Files
When a copy of MetaBase.xml is written to the History folder, the value of the HistoryMajorVersionNumber property is incremented and added to the names of the file pair. If edit-while-running is enabled, and the user makes a manual change to the metabase, the minor version number is incremented and added to the names of the file pair.
The file names of versioned MetaBase.xml files and MBSchema.xml files are created in the following format, respectively, where both the value of the HistoryMajorVersionNumber property and the minor version number are 10-digit numbers:
MetaBase_HistoryMajorVersionNumber_MinorVersionNumber.xml
MBSchema_HistoryMajorVersionNumber_MinorVersionNumber.xml
When either the HistoryMajorVersionNumber or the minor version number value is less than 10digits, the number is padded with zeros in the file name to create a 10-digit number. This keeps the file names aligned and in numerical order when you sort by file name, making the contents of the History folder easier to read.
The following is an example of file names in the History folder:
MetaBase_0000000001_0000000000.xml
MetaBase_0000000001_0000000001.xml
MetaBase_0000000002_0000000000.xml
MetaBase_0000000002_0000000001.xml
MetaBase_0000000002_0000000002.xml
MetaBaseError_0000000000.xml
MetaBaseError_0000000001.xml
MBSchema_0000000001_0000000000.xml
MBSchema_0000000001_0000000001.xml
MBSchema_0000000002_0000000000.xml
MBSchema_0000000002_0000000001.xml
MBSchema_0000000002_0000000002.xml
For each instance of a MetaBase_MajorVersion_MinorVersion.xml file within the History folder, there is an MBSchema_MajorVersion_MinorVersion.xml file of the same version that is used with the metabase configuration.
Metabase Error Files
File names that contain the word error are created in the History folder under the following circumstances:
Edit-while-running is enabled.
You edit MetaBase.xml directly by using an application, such as Notepad.
An error, such as (but not limited to) the following occurs:
An XML tag is omitted in MetaBase.xml.
A property name is misspelled in MetaBase.xml.
The corresponding history file with the same HistoryMajorVersionNumber value as MetaBase.xml is not found.
Error files are named in the following format, where TenDigitNumber is the version number of the error file, starting with version number 0000000000:
MetaBaseError_TenDigitNumber.xml
The version number increases by one for each additional error file that is created.
Restoring the Metabase
Restoring the metabase from history files is similar to restoring it from backup files. For a comparison of the two methods of restoring the metabase, see Table4.6.
Table4. SEQ Table \* ARABIC 6Comparison of Metabase Restore Methods
Using Backup FilesUsing History FilesIf a password is provided by the user to encrypt secure properties, the metabase can be restored to a different installation of Windows, even on a different computer.The metabase can be restored only on the same installation of Windows from which the history files were created. This is because data is encrypted with the machine key in the backups.Backup files can be created on demand, scheduled, or created by using a programmatic administration script.History files can be created automatically (when the IIS history feature is enabled) or by using a programmatic administration script.Backup files can be restored from IIS Manager, by using APIs or by using programmatic administration scripts.History files can be restored manually or by using IIS Manager.
Restoring the Metabase from History Files
The following procedures describe how to use automatically generated history files to restore your IIS configuration.
To restore the metabase using IIS Manager
In IIS Manager, right-click the local computer, point to All Tasks, and click Backup/Restore Configuration.
In the Backups list, click the Automatic Backup you want to restore, and then click Restore.
Read the message that appears, and click Yes if you want to continue.
Click OK.
You might find it necessary to restore the metabase without using IIS Manager. For example, if a configuration change is made improperly or if it is made with incorrect XML syntax, and IIS Manager is unable to enumerate the metabase, use the following procedure to restore the metabase. Note that this method should be used only as a last resort. If at all possible, use metabase history or backup files to restore the metabase.
Important
You must be a member of the Administrators group on the local computer to run scripts and executables, or you must have been delegated the appropriate authority. 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:MyMachine\Administrator cmd to open a command window with administrator rights and then type cscript.exe ScriptName (including the full path with parameters, if any).
To manually restore the metabase
From the Start menu, click Run.
In the Open box, type cmd, and then click OK.
At the command prompt, type iisreset /stop /noforce, and then press ENTER.
If the IIS services do not stop, and it is possible to restart the computer, type iisreset /stop /rebootonerror, and then press ENTER.
At the command prompt, type cd %systemroot%\System32\Inetsrv, and then press ENTER to navigate to the folder where the files are. Next, type copy MBSchema.xml MBSchema.old, and then press ENTER to copy the schema file. Finally, type copy MetaBase.xml MetaBase.old, and then press ENTER to copy the metabase configuration file.
At the command prompt, type cd %systemroot%\System32\Inetsrv\History, and then press ENTER.
At the command prompt, type dir, and then press ENTER. All of the files appear in the following format: