Here at The Port we inevitably wind up doing a lot of tinkering with the IIS metabase in the course of supporting our server tools. And one of the things we've discovered is that the metabase is less well understood than it should be by some IIS admins. So here is a very quick run down on what the metabase is and how it works. This is basic stuff, but having a good picture of it in your head will help with things like backup and restore, importing and exporting, hand editing, migration, and admin scripting.
First, you should know that the metabase is where IIS stores most of its settings (a few are also stored in the registry). Your Internet Information Services Manager is largely just a convenient GUI through which you access the metabase to examine or change IIS's configuration settings.
Next, it's good to keep in mind that the metabase isn't just a file (or files). In addition to the aspect of the metabase that is persisted on your server's hard disk, there is also what is called the in-memory metabase. The in-memory metabase is the one whose settings are actually in control of IIS at any given time. This can be a useful thing to remember.
In IIS 6.0, there are two files: MetaBase.xml and MBSchema.xml, stored in %SystemRoot%\System32\inetsrv. In IIS 5.0, it's just one file, in proprietary format similar to the registry: metabase.bin. But in both cases, there is also a copy of the metabase in memory.
Where in memory? Well, in the IIS file cache, as a matter of fact.
Now this in-memory metabase is where your changes actually get written, most of the time. The only exception is if you edit MetaBase.xml directly (IIS 6.0 only, obviously).
So now you should be asking: When does the in-memory metabase get written to disk, to synch it up with MetaBase.xml?
One way this happens is when the IIS Admin service is stopped, and you've made changes to your IIS configuration that are still in the in-memory metabase, waiting to be saved to disk. But IIS doesn't wait for this event. 60 seconds after any change, it writes the in-memory metabase to disk. The only exception is the case when a bunch of changes (30 actually) have happened within a minute, in which case IIS puts off writing the in-memory metabase to disk, figuring that more changes are on the way. It will only do this delay five times in a row, however, after which the changes get written even if they are still coming.
Now comes one of the really cool things about the IIS 6.0 metabase: Each time the in-memory metabase get written to disk, an automatic backup of the previous version gets made for you. In case you were wondering, that is how all those entries called "Automatic Backup" got into your ISM's Configuration Backup/Restore dialog (which you get to by right-clicking the Server node and going to All Tasks >> Backup/Restore Configuration).
The files themselves actually live in %SystemRoot%\System32\inetsrv\History and, if you look there, you'll notice that they are named things like MetaBase_0000000147_0000000000.xml and that there are ten of them each for the metabase.xml and for the schema (this number can be adjusted by -- editing the metabase of course!). The numbers in the file names are actually version numbers. The first one is incremented every time an automatic backup gets made in the way mentioned above.
When does the second number get incremented? Well, you've probably heard of that other cool IIS 6.0 metabase feature called edit-while-running, right? This allows you to make changes directly to the metabase.xml file without shutting down IIS -- which would normally be required when doing this. When you enable edit-while-running, and then make and save changes, obviously there is no need for IIS to write the in-memory metabase back to disk (instead, it has to synch the in-memory metabase up with the changes you just made to the text file). So, you get a slightly different type of automatic backup to correspond to the different editing procedure. Of course, if you need to restore the metabase from that history file, it works exactly the same as a major version one, using the Configure Backup/Restore dialog in your ISM.
That's probably enough for now, but we'll most likely be returning to this topic quite a bit in the future because, from our point of view, the more IIS admins out there who know their way around a metabase, the better!