Hack 54 Back Up the Metabase

There's more than one reason for backing up the metabase, and there are different ways of doing it too .

Instead of storing its configuration settings in the Windows Registry, like most other services store their configuration settings, IIS stores most of its settings in a file called the metabase . On Windows 2000 (IIS 5), the metabase is a binary file named MetaBase.bin , found in the %SystemRoot%\system32\inetsrv folder. Windows Server 2003 (IIS 6) uses XML as the format for its configuration information, rather than the proprietary binary format used by IIS 5. As a result, there are two metabase files in IIS 6: the metabase proper ( MetaBase.xml ), where configuration settings are stored, and an associated XML schema file ( MBSchema.xml ) that defines the XML syntax of the MetaBase.xml file. Because of the differences between these two platforms, we'll have to consider them separately when backing up IIS settings.

Why Back Up the Metabase?

Many IIS administrators don't realize that there are two reasons for backing up the metabase and each reason requires a different method for doing so. The most obvious reason is to prepare for the eventuality of a disaster. Note that I said eventuality instead of possibility , because wise system administrators know that it's only a matter of time before something horrid happens. To prepare for such a disaster, you certainly want to back up the metabase on your IIS machines, but having a backup of the metabase alone isn't going to be much help if the hard drive containing your boot volume is toast ; the proper functioning of the metabase depends on having access to some encryption keys that are part of the System State on your server. System State is a fancy phrase for a collection of important configuration information that lets you recover the predisaster state of your system after a massive failure renders it unbootable. You'll find more information about what's included in a server's System State in [Hack #92] in Chapter 10.

So, here's the point: if you back up the IIS metabase without its associated System State, you won't be able to recover your web server after a disaster. Microsoft doesn't document clearly in either their Windows help files or on their web site that, by default, when you back up the System State information on a Windows 2000 or Windows Server 2003 machine, you also automatically back up the metabasethat is, if you've left your backup settings at their defaults. Let's dig a little deeper.

Advanced Backup Settings

Hidden away in the Windows Backup utility is a properties box called Advanced Backup Options (Figure 6-1). To access Advanced Backup Options, select the items you want to back up, click Start Backup, and then click Advanced.

Figure 6-1. The Advanced Backup Options properties box in the Backup utility

When you choose to back up the server's System State, the setting "Automatically backup System Protected files with the System State" is selected by default. This setting actually backs up the entire contents of the %SystemRoot% folder and all its subfolders along with the rest of the System State information on the server. Of course, the inetsrv directory where the metabase is found is part of this directory hierarchy, so the metabase gets backed up along the way. So, if you want to back up the IIS metabase for comprehensive recovery from a disaster, simply back up the System State using Backup (or its command-line version, ntbackup ). Since the "Automatically backup System Protected Files with the System State" checkbox automatically adds several hundred megabytes to the size of your System State backup, if you're the kind of person who likes living dangerously and you want to save on tape and speed up your backup, you could deselect this checkbox. Naturally, it's usually best to avoid cutting corners like this and leave the setting checked.

Quick Backups

Preparing for that eventual disaster isn't the only reason for backing up the metabase. You should also make backup copies of the metabase if you plan on tinkering with it, either using MetaEdit ( metaedit.exe )a tool in the Windows 2000 Server Resource Kit, used for editing the IIS 5 metabaseor a text editor such as Notepad, which you can use to edit the XML metabase of IIS 6 directly. The danger here is that indelicately laying hands on the metabase might break something and render your metabase unreadable to IIS, forcing you to restore before your WWW Publishing Service starts again and users can access your web sites. The syntax of the metabase is strict, and any untoward alterations could cause a service to behave unpredictably at best, or just fail altogether at worst. So, before you roll up your sleeves and start fiddling with your metabase, it behooves you to make a quick backup.

You could back up the entire System State on your machine before touching the metabase, but that's overkill. You could use Backup to back up only the inetsrv directory on your server, but there are faster and simpler ways.

IIS 5

You can back up the metabase from the GUI by using Internet Services Manager, the MMC console used for configuring and managing IIS. Right-click on the node that represents your server and select Backup/Restore Configuration to open a dialog box of the same name, as shown in Figure 6-2. Click the "Create backup..." button, type a descriptive name for your backup, and click OK. Backups are stored in the %SystemRoot%\System32\InetSrv\MetaBack directory; to be extra careful, you can include this directory in your regular tape backups.

Figure 6-2. Backing up the metabase

Restoring the metabase is just as straightforward: select the metabase backup you want to restore and click Restore.

If you're using MetaEdit to editing the IIS 5 metabase, you're in luck; conveniently enough, MetaEdit itself is capable of making quick metabase backups.

Before you start using MetaEdit, however, be sure to download the latest version of the tool from Microsoft's web site. Interestingly, when you search the Microsoft Download Center (http://www.microsoft.com/downloads/) for metaedit , you only get Version 2.0 of the tool, which is out of date. To obtain the latest version of the tool (MetaEdit 2.2), see Microsoft Knowledge Base article 232068 (http://support.microsoft.com/default.aspx?scid=kb;en-us;232068), which has a link to the installation package.

Once you download and install the self-extracting file, you have two tools to play with: a Metabase Browser/Editor similar to Registry Editor and a Metabase Consistency Checker designed to ensure the syntax of the metabase remains consistent. Unfortunately, the Consistency Checker isn't too useful, because it won't repair certain types of mistakes you can make with the Browser/Editor, such as entering illegal values for metabase keys. So, just like when you edit the Registry directly, you're on your own and in dangerous territory.

In fact, it's always a good idea to back up the metabase periodically, even if you make changes to your metabase only through the Internet Services Manager GUI. That way, if you make a lot of configuration changes to IIS and discover your web applications acting a mite odd, you can reverse those changes quickly and easily by restoring the metabase from recent backup. In fact, this might be the only way to return to a working IIS configuration if you can't remember all the changes you've made. So, regular metabase backups are a part of good housekeeping on your IIS machines.

Backing up the metabase with MetaEdit is straightforward: simply open MetaEdit (it's installed by default under Administrative Tools) and select Metabase Backup/Restore from the menu. This opens the same Configuration Backup/Restore dialog box (Figure 6-2) and saves backups in the same MetaBack directory as before. GUI- and MetaEdit-made backups are compatible, so you can back up using one way and restore using the other if you prefer.

Remember that these quick backups of the metabase are designed only to recover from a corrupt metabase or to restore the metabase to an earlier working condition; you cannot use them to restore an IIS machine from scratch; use System State for that. Also, note that a metabase backup made on one machine cannot be restored to a different machine, due to the differences in System State information between the machines. There's a workaround for that too, though: export the metabase instead of backing it up. Exporting saves all or part of the metabase in a text file instead of in the proprietary binary format used for metabase backups. Note that exporting the metabase requires you use MetaEdit, because export functionality is not included in Internet Services Manager for IIS 5.

Exporting the metabase is useful if you want to document the contents of your metabase by printing it out. It's also useful for copying web site configurations from one IIS machine to another. For example, if you want to mirror a site on two machines, simply export the metabase keys for the web site and then import the export file into the second machine. But don't forget to copy your site content as well; remember that the metabase contains only IIS configuration information, not the content of your web sites.

IIS 6

Metabase backups are even easier in IIS 6, because the functionality is built right into Internet Services Manager. In fact, in addition to allowing you to back up the metabase manually, IIS 6 also automatically backs up the metabase whenever configuration changes have been made. Let's look at these automatic backups first.

IIS 6 automatically saves time-stamped (versioned) copies of the metabase; these copies are called history files and are saved in the %SystemRoot%\system32\intesrv\history folder. History files are identified by two numbers : major version and minor version. The major version number is incremented whenever you stop and start IIS using the GUI or net stop iisadmin on the command line, when IIS flushes the in-memory metabase to disk, or when you manually save the IIS configuration to disk. This provides a safety net, so you can recover an earlier configuration if you've made a series of changes and can't remember what they were, let alone how to undo them. When a new major version history file is saved, IIS includes a reference to this file in the MetaBase.xml file itself.

Minor versions are somewhat different. IIS increments the minor version number if you have edit-while-running enabled and make modifications to the metabase while IIS is running. Edit-while-running is a new feature of IIS 6 that allows you to edit the metabase directly while Iisadmin and other IIS services are still running. Whenever the major version number is incremented, the minor version number is reset to 0.

If you plan to use the new history feature of IIS 6it's enabled by defaultyou will probably want to modify the history settings to suit your needs. The default history settings save a maximum of 10 history files before overwriting the oldest file. This might not be enough history if you plan to edit the metabase extensively; you might want to increase this number to 20, 30, or even 100. Make sure you have sufficient disk space for all these files, however; if IIS can't create a new history file due to insufficient disk space, it will automatically shut down without warning or explanation.

To change the maximum number of history files IIS should save, you'll have to modify a metabase setting directly; there's no way to do it from the GUI. The property you need to change is called MaxHistoryFiles and it's located in the <IIsComputer> section (if you're navigating the metabase by its key hierarchy) or the LM location (if you're navigating by location hierarchy) of the XML code. The metabase can be a confusing place; you might take a gander at [Hack #56] for guidance.

After you make changes to the metabase directly, check the history folder for any error files that might have been created. These error files are named in the form MetaBaseError _ versionnumber .xml and are generated when metabase corruption has occurred after editing. If you see an error file, restore your metabase to the previous history version and try editing it again.

IIS 6 also lets you manually back up the metabase and export portions to a text file, similar to what we did in IIS 5. The main difference is that in IIS 6 export functionality is built directly into the GUI, so you no longer need the old MetaEdit tool for exporting. In fact, you can't use MetaEdit with IIS 6 because of the metabase's format change from binary to XML.

GUI differences between IIS 5 and IIS 6

Backing up the metabase from the GUI is done the same way as it was in IIS 5, with a couple of important differences. First, an initial metabase backup is automatically performed once you install IIS on your machine (to reduce the attack surface of your machine, Windows Server 2003 no longer installs IIS by default). This initial backup consists of two backup files: an *.MD0 file that contains a backup of MetaBase.xml (the metabase proper) and an *.SC0 file that holds a backup of MBScehma.xml (the XML schema that defines the syntax of MetaBase.xml ). Note that in IIS 5 the schema is included as part of the single metabase.bin file, though in MetaEdit the configuration ( LM ) and schema ( Schema ) portions of the metabase are displayed as two separate nodes. In other words, every time you back up the metabase in IIS 6, you back up both the configuration file and the schema.

Here's another difference. In IIS 5, using Internet Services Manager, you right-click on the server node and select Backup/Restore Configuration. To do this in IIS 6, however, you right-click on the server node and select All Tasks Backup/Restore Configuration. This is just one example of the unnecessary, minor changes in Windows Server 2003 that cause frustration for administrators who are used to working with Windows 2000.

You can also now use a password to encrypt metabase backups. An encrypted metabase backup can be restored to a different IIS machine, which gives you a way to clone the IIS configuration of one machine and copy it to another. This was not possible in IIS 5; you could restore a metabase backup only to the same machine and only if you hadn't rebuilt the machine onto new hardware after a disaster. This is one of many good reasons to upgrade your web servers to Windows Server 2003, even if you choose to keep your domain controllers running Windows 2000. Just don't forget the password you use to encrypt your metabase or you won't be able to restore from the saved backup.

Finally, IIS 6 also includes some scripts that can be used to back up and restore the metabase from the command line. For more information about these scripts and what they can and cannot do, see [Hack #59].