As mentioned previously, the metabase is the single repository or location for the storage of configuration information relating to IIS 5.0.
The metabase is organized similarly to the Registry, in that it uses a hierarchical structure of keys and values (see Figure 1). The nodes in the metabase tree are called keys. These keys contain values that relate to IIS configuration values and are known as metabase properties.
If you are coming to IIS 5.0 from earlier versions, you are probably accustomed to dealing with the IIS configuration keys in the Registry. These values are now stored in the metabase, which offers a unique capability to assign the same property differently for different nodes. You will also find that the metabase provides faster access times because it is stored in RAM when the server is running.
Figure 1 The IIS Administration Objects are displayed, showing their relationships.
The topmost key is the IIS Computer key. This key contains properties that will be set for the entire IIS service on the computer. The keys then break into separate services, one for the FTP services and one for the Web services running on the computer.
Each service contains keys that are specific to it. Under the FTP Service key, you will find keys relating to FTP servers. Notice that I said servers because you can have more than one. Likewise, the Web Service key can have more than one Web Server under it. If you make changes to the Web service or the FTP service, it will affect all servers running on the computer. As we discussed previously, you can make changes at an individual Web or FTP server and have those changes override the global ones set at the service or computer level.
Key Names and Paths
When talking about keys in the sense of the metabase, you can compare them to a directory in a file structure. These keys can form a path by being placed in sequence and being separated by a forward slash (/).
You can have keys with the same name in the metabase, provided that they are placed in unique paths, in much the same way as you can have two files with the same name in different directories in the computer.
In order to access a specific key with the IIS Admin Objects, you need to specify the complete path to that key. This path is known as the ADSI path and is called AdsPath. This path always starts with IIS:// and then the IP address or hostname of the computer. An example would be IIS://localhost/W3SVC/1, which would access the first Web Server located on the local server.
Each Web or FTP server has a root directory or virtual root associated with it. In order to access the root directory in the previous example, you would specify it like this, IIS://localhost/W3SVC/1/ROOT. All other directories will be subdirectories of this.
Most of the properties that make up the metabase are inheritable. This means that you can get away with only a few settings and can minimize the memory used by the metabase. Higher-level keys can assign their properties to lower-level keys; that is, the lower-level keys can inherit the settings of the upper-level keys. A good example of this is when you set file permissions such as write or execute at the service level, W3SVC. All identical keys under this root key inherit these settings, unless you set a specific key differently.
If you are using the IIS snap-in and you set an inheritable property, you will see a dialog box asking for the subnodes on which you would like to set the property. If you set an inheritable property through script, the subnodes will inherit the settings automatically.
Security and Reliability
The metabase resides in memory. Obviously, it will not persist if the computer is rebooted or shut down. For this reason, the metabase is stored on disk and is loaded into memory when IIS starts. Periodically, IIS will save the metabase to disk to ensure that recent changes are preserved. When you shut down IIS, the metabase gets resaved to disk.
The metabase file is named Metabase.bin, by default, and is located in the Inetsrv directory. It is very important that this file be protected against unauthorized access and be placed on an NTFS partition where the proper security access permissions can be set.
You can move this file to another directory or rename it. When you do this, however, you will need to make the necessary changes to the Registry so that IIS can find the file when it starts up. The Registry key that you need to configure is this:
HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \InetMgr \Parameters
You need to add a value to this key of type REG-SZ and name it MetadataFile. MetadataFile specifies the complete path to the metabase, which must include the drive letter and filename.