Windows Update and IIS Metabase Corruption?
I let the most recent windows updates install on Server 2003 x64 this morning, and the first thing I noticed on reboot was that familiar but despised messagebox, "One or more services failed to start, have a looky at the Event Viewer, etc.".
Now, I can't be sure if it was the update, I'm just mentioning this in case other poor souls want to corroborate, in addition to the fact that I know of at least one other situation where this may have occurred.
At any rate, the IIS Admin service would not start. A bit of investigation revealed that the IIS Metabase, "Metabase.xml", which resides in %windows%\system32\inetsrv\, was corrupted.
If you have enabled backups on your IIS metabase, there are three ways to restore a previous backup. You can do it from IIS Admin snapin (the preferred method). However, if (as in this case) the Admin Service won't start, you are pretty much S.O.L. on that one. Another way is to do a restore of your backed - up System State, but in many cases that would result in so much additional "Bad Baggage" being restored that you really want to avoid it.
The third way, is to look in the History Folder, and you'll see a bunch of files that look like "MetaBase_0000003275_0000000000.xml". All you need to do is copy the latest one (assuming it's not a backup of the corrupted one, of course), copy it back into the inetsrv folder, and rename it to "Metabase.xml".
Presto! You're done, and the IIS Admin service should start. Of course, you may have to reconstruct some VRoots and stuff, but it's quick and pretty much failsafe.
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.
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.
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.
Now! The question becomes, how did my Metabase xml file, which has never been corrupted before, ever, get corrupted like this?
Now, I can't be sure if it was the update, I'm just mentioning this in case other poor souls want to corroborate, in addition to the fact that I know of at least one other situation where this may have occurred.
At any rate, the IIS Admin service would not start. A bit of investigation revealed that the IIS Metabase, "Metabase.xml", which resides in %windows%\system32\inetsrv\, was corrupted.
If you have enabled backups on your IIS metabase, there are three ways to restore a previous backup. You can do it from IIS Admin snapin (the preferred method). However, if (as in this case) the Admin Service won't start, you are pretty much S.O.L. on that one. Another way is to do a restore of your backed - up System State, but in many cases that would result in so much additional "Bad Baggage" being restored that you really want to avoid it.
The third way, is to look in the History Folder, and you'll see a bunch of files that look like "MetaBase_0000003275_0000000000.xml". All you need to do is copy the latest one (assuming it's not a backup of the corrupted one, of course), copy it back into the inetsrv folder, and rename it to "Metabase.xml".
Presto! You're done, and the IIS Admin service should start. Of course, you may have to reconstruct some VRoots and stuff, but it's quick and pretty much failsafe.
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.
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.
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.
Now! The question becomes, how did my Metabase xml file, which has never been corrupted before, ever, get corrupted like this?
Yes, that's my question too. I have to repair the metabase on about 10% of my servers per month. This used to be triggered by Windows Update but now, all it takes is a reboot for some servers. Another interesting thing - it's not always the same servers experiencing the problem. What is the cause of this issue?
ReplyDeleteMG2