MMC Loses IIS 4 Configuration Data When Changing IP Addresses - 6/16/00

All the Internet Information Server (IIS) 4 configuration data disappeared from Microsoft Management Console (MMC) TWICE while changing IP addresses in preparation for an SDSL line install. In subsequent months, the data disappeared multiple times for no discernable reason. MMC is now my nomination for the stupidest piece of software ever written.

Now that I finally have a firm SDSL install date for next Monday, I've been spending a lot of time on all the systems doing a variety of things to get ready for a full time connection to the Internet. A number of things relate to networking, administration and security but hopefully it's obvious why those topics won't be publicly discussed in any detail.

While my computers have been on an isolated LAN, I've used one of the standard private IP address ranges. Now that the sites will be going public, at least the servers hosting web sites will need to be visible to the Internet with valid IP addresses. My original plan was to host my own DNS servers but this looks like it may be too ambitious. Besides looking like a lot of work on both the UNIX like and NT systems, I learned during my initial investigation that the Internic no longer makes the list of root servers necessary to do this publicly available. What I must do at a minimum is change the IP addresses the web servers are on. This means both the machine IP addresses and the addresses the web server software is servicing.

On Linux, the machine addresses are easy either from the command line (if you know some networking basics) or linuxconf. I took the wrong approach on the Linux system to the Apache virtual directories and have lost access to the GeodSoft.com site again. I'm pretty sure I know what to do and will be reporting more on this later.

Changing the IP addresses on NT looked quite straight forward (with 3 plus years administering NT servers and IIS 3 & 4). I have a number of virtual web sites on the NT machine and making the changes does involve both the networking control panel and the IIS Management Console and working through several layers of dialog boxes. I very much doubt that many persons doing this the first time on their own would get this right. On the other hand when you compare the NT GUI to its counterpart in linuxconf, its clear that except for being in two places, that NT has more options, more clearly explained and is the more robust interface.

This could have and should have been much easier on the NT machine except that I ran into a problem. The last time that I had to change a machine's primary IP address on NT and IIS 4 I used an invalid IP address and then rebooted after correcting it. I forgot to change IIS to match and when I started the Management Console to make the change ALL the configuration information was gone. Fortunately, reinstalling with all the existing options brought it back. With IIS 4, Microsoft has moved the configuration information out of the registry and into separate databases managed by the Management Console. The data wasn't really gone but MMC apparently couldn't find it and reinstalling corrected this (or so I thought).

I was not going to make the same mistake twice and was very careful this time to be sure change all the IP address in both the networking control panel and IIS MMC and double checked to be sure they matched before rebooting. After rebooting I checked each virtual site from the browser of another machine and everything looked good. I was thinking that for this task, NT was clearly easier than the Red Hat system (though I do have much more NT experience in this area).

Then I wanted to make another change and opened MMC. Once again there was no configuration information: no default site, no virtual site, no virtual directories, no ftp sites. Clearly the information is still on the hard disk somewhere and IIS can find it because all the sites are working just fine but MMC can't find it. The Index Server MMC looks OK but I didn't document the settings and I'm not sure about some of them. I think they are OK but there are some odd things I've noticed like some program directories being indexed. I never paid a lot of attention to all the things that came with the initial IIS 4 install so these may have been there all along. If I ever get things working right on this machine again I'll certainly experiment with removing these.

At this point I'm in a serious quandary. Do I try to fix things by spending time looking for recently updated files on disk and trying to find the registry entries that point MMC to it's file. I'm assuming Microsoft still uses the registry to that extent. Even if I'm successful there's a risk I'll never get things consistent. On the other hand, I surely do not want to uninstall everything and start over from scratch with IIS 4 and Index Server! ? ! ? ! ?

It looks like I may SOL. I've spent a good while looking. There are registry entries under hklm\software\microsoft\mmc but none of them point to any file locations. There is also an mmc.ini file in the Windows NT root directory that looks just like the Windows 3.1 .ini files! It does have the names and locations of two .msc files which are also among the files modified in the past day. Double clicking on these .msc files starts MMC with the same configuration information displayed as the start menu or desktop icons to the IIS and Index Server Management Consoles so these are clearly the files that MMC is saving it's information in. Its also clear that IIS is getting it's configuration information from a metabase.bin file located in the same directory as the IIS executable and the IIS.msc file. This file was modified last night after IIS.msc. Since there are no references to "metabase" anywhere in the registry on in an .ini file that I can find, I assume that IIS expects to find metabase. bin in it's own directory.

Metabase.bin is a bizzare binary format file. Looking at it in display program with hexadecimal display options, all the virtual directory names and paths are in this file but with each character separated from the next by a null (hex 00) character. These are interspersed with areas of pure binary data. It's as if Microsoft wanted to make it hard to do anything with this file.

I tried a couple more installs (add/upgrade components) and doing some things in different orders and stopping the services while doing the install. Nothing worked so I thought I'd manually put back all the missing virtual servers and directories. When I went to add, there was no web site option. It now looks like the only option is too uninstall everything and start from scratch! I wish I had current backups but suspect they wouldn't do me any good. The fact is that two out of two times that I've had to change the primary IP address on an NT server with IIS 4, all the IIS settings have disappeared. With backups I could try some other variations and possibly see if what I suspect is the cause is really the problem.

Though I don't and never will know what the real cause of the problem was, the fact remains that I have to get from where I was yesterday to where I tried to go. Backups would only get back to where I was yesterday. They wouldn't give me the route to where I need to be. Since I've now seen Microsoft web server software corrupt/loose it's own configuration data twice under similar circumstances, I have no reason to believe that it would do any better if I started once again from where I was yesterday.

After un installing "all" NT Option Pack components and then manually removing the pieces that the uninstall did not remove, doing a thorough system clean up and then making backups, I reinstalled the option pack. Not surprisingly, it hung very near the end. The second install saw enough of the first that it did not behave like a new install but instead acted like an upgrade/add/remove components install with all my previous choices already selected and no option for an install location. Like so many Microsoft installs that die or hang for no apparent reason and then subsequently complete normally, this one appeared to go to a normal completion in that there were no hung dialog boxes left on the screen and the web and ftp services were running afterwards. The install didn't even ask me to reboot. I thought it was serving the wrong pages but that turned out to be a browser caching issue. (I had deliberately avoided telling the install to use the GeodSoft.com root directory as the web default document root because I did not want the documentation and other IIS directories under mine and was more than a little surprised when my home page showed up even after refreshing.)

IIS is serving pages but it won't let anyone see my public pages without prompting for a user name and password. I've done nothing to change the disk security and anonymous access has been working fine as long as I've had the GeodSoft.com site. Anonymous access is explicitly allowed in this server but no matter how many times I check and recheck the various IIS setting and stop and start the server, it won't let me in without a password.

In trying to figure out what was going on, I went to look in directories IIS was installed in and it wasn't there. I know where I specified to be installed but Microsoft installed it into the "default" location. I suppose it had something to do with the hung install and no choice on the second time. I've successfully put IIS where I wanted it before and the MMC.ini file even had an entry for there but there was an newer entry pointing to the new location. I'll see if it can be relocated by copying all the files and changing MMC.ini.

Previously I made the mistake of thinking there were no registry entries for IIS because I didn't find references to "metabase". After switching the directory locations around (the old directory was kept with a different name) I rebooted. There was an error message that a service could not start and not surprisingly it was the web service. The error message indicated that IIS components could not be found. This time I searched the registry for the directory name and found 146 registry entries pointing to the directory. There are only 66 files in the directory so that's 2.21 pointers per file. Actually there was at least one pointer just to the directory. I suppose it's just too simple and obvious to have one pointer to the directory.

This is a perfect example of why Windows is and always will be inherently unstable. If any one of those 146 entries is changed or damaged, some part of IIS most likely won't work. If you're lucky like I was, it won't work at all and you'll get an error message that lets you fix the problem. If you're unlucky, a pointer to an occasionally used DLL will be damaged and you'll end up with a problem visible to web site users that happens infrequently enough that you'll loose some visitors or customers but no one reports it. Even if it gets reported, it might be very difficult to track down.

This kind of unnecessary redundancy is bad. It's why uninstall programs never really remove everything and Windows registries keep growing and slowing down the system as it ages. It's why simple upgrades break things because someone lost track of 146 places to change something that should only need to be changed once (or twice or few times maybe). Even if an upgrade doesn't break things it leaves orphans behind. It's why Microsoft refuses to support any direct changes to the registry even though that's often the only way to fix a Windows problem. It's also too easy to damage something and there's no going back when you save a registry change. If you haven't exported it first or made exact notes on it's contents there is no way to get a single entry back without doing a full registry restore. BTW, don't ever double click on a .reg file. If it's a valid registry export, Windows will reload it into the registry without any prompt or warning or opportunity to abort. If the top level key that's reloaded has any new sub keys or changed data, they're gone.

I gave up on relocating the IIS directory to where I wanted it. It's just too much work to switch 146 registry entries and then go and change all pointers to the virtual directories in the IIS MMC. I put things back the way they were and IIS started again.

I finally found the problem regarding logins. Since it was security related and I'd been looking at IIS setup and file permissions and could not find anything, I finally went into Usrmgr and as soon as I saw the user names, knew what the problem was. In addition to changing IP address, I've been changing host names. I completely forgot that because I did a full new install of IIS after changing the name, that it would create a new user, IUSR_computername, for the anonymous access. The old anonymous user still had read access to the public web directories but the newly created one did not. As soon as I gave the new anonymous user read access to the public web directories, the password prompt went away.

THIS IS UNBELIEVABLE! While trying to figure out what was going on I tried a new IP address for the GeodSoft.com site. When I finally figured out the real problem, I deleted the unnecessary IP address and set all the web addresses back to where I'd started and what I wanted. The FTP site had in the meantime picked up the extra address and I did not think about this. I rebooted without the unnecessary IP address. When I returned to MMC, I got an error message that to the effect that it could not enumerate the IP addresses for the FTP site. When I got back into the management console ALL THE CONFIGURATION DATA WAS GONE AGAIN!

Microsoft Mangement Console is now a prime candidate for the stupidest piece of software design I have ever seen. There's an error in some data so lets hide the data so it can't be fixed. How dumb can you get? Before I made any other changes, I put back the IP address I did not want and rebooted. The data was still there and now visible. All the web and FTP services were stopped. There's an inconsistency between the web set up and the networking set up. Which is more likely to be right? Only Microsoft, which is the only company that pretends to make enterprise software that requires a reboot to add or change an IP address, could come up with forcing you to make your changes where you have to reboot to put them into effect.

THREE REBOOTS TO GET RID OF ONE UNWANTED IP ADDRESS! First to do it they way you want it. Second to put it back to the wrong way so you see the data that still needs to be changed. Third to put it right again. Of course it also means that all this grief I've gone through for the past day plus has been unnecessary. As I knew from the begining, the data was there somewhere. Had I put back the entire old and now wrong IP setup it would most likely been visible again. But that also means the computer is effectively no longer networked for the duration. It was probably the FTP data that caused the problems since at least initially the web servers were working just like I wanted.

Top of Page - Site Map

Copyright © 2000 - 2014 by George Shaffer. This material may be distributed only subject to the terms and conditions set forth in http://GeodSoft.com/terms.htm (or http://GeodSoft.com/cgi-bin/terms.pl). These terms are subject to change. Distribution is subject to the current terms, or at the choice of the distributor, those in an earlier, digitally signed electronic copy of http://GeodSoft.com/terms.htm (or cgi-bin/terms.pl) from the time of the distribution. Distribution of substantively modified versions of GeodSoft content is prohibited without the explicit written permission of George Shaffer. Distribution of the work or derivatives of the work, in whole or in part, for commercial purposes is prohibited unless prior written permission is obtained from George Shaffer. Distribution in accordance with these terms, for unrestricted and uncompensated public access, non profit, or internal company use is allowed.