Head to Head: Win2K vs. Unix Server Migration

I recently found myself having to migrate our user data from one Windows 2000 Server system to another. For one, the server had been compromised, and for two I wanted to strip the server and rebuild/reinstall from scratch to my specs rather than continue to deal with the poor configuration I had inherited. The data in question includes websites and email for approximately a hundred domains for local business customers. What I thought would be a simple task turned into a major undertaking and a severe pain in the neck, and reaffirmed my preference for Linux and FreeBSD over Windows in server roles.

Right now I run a mixed environment of Linux, FreeBSD and Win2K servers. One FreeBSD system is a mixed email and web server for our home users, and shortly after I was hired I had to rebuild it. Moving the data off of the server, rebuilding it, and migrating the data back was extremely simple: everything is a text file. With the help from basic utilities like cat and pico, I was able to quickly and easily rebuild the user database, which was the only worrisome part of the whole process. Web and mail server configurations are just a single text file, and all user data is contained in the appropriate home directories.

On the Windows side, we use a proprietary mail server and IIS. The mail server wasn’t so bad, as user email is stored in text files in Unix mbox format, and each domain has its own folder. We simply moved the directories over and used regedit to migrate the user settings and email was back up and running. If only IIS were so easy.

IIS 4 on NT had a simple export utility. I never had to migrate a server, but I was able to save my configuration settings to back them up. This file could in turn be saved anywhere, even to a floppy. IIS 5 on Win2K, however, does not work quite the same. It creates a .MD0 file in the web server directory, and is managed by the IIS backup/restore utility. We first tried copying this file over and restoring it, but it just doesn’t work this way. Fortunately we did this offline for testing, not during the actual migration process.

We found a web migration tool in Microsoft’s IIS Resource Kit. We downloaded and installed it on both servers per the instructions, one the source and the other the target. It’s easy enough to use, as it’s all run from Internet Explorer. There are three checkboxes for each domain: settings, content, and MIME types. We chose a handful of low-traffic, low-impact domains to test, migrating all three items. Everything went fine, and after a quick tweak to the network settings for the new domains, the sites worked fine. We made plans to do the rest of the migrations late on a Saturday night when impact would be minimal.

We had already moved the customers’ web spaces to the new machine, but we went ahead and checked the content box to be sure we had the most recent data. The utility warned us that it would take a while, and after 45 minutes with no end in sight, we stepped out for a quick bite to eat. When we came back, we found the migration had failed, claiming there was no space remaining on the destination. This didn’t make sense at first as we had more than enough space for the data.

Long story short: the migration utility creates a .cab file creating all the data to be migrated. It brings the cab file over to the new machine and unpacks it, but it does so in the C: drive and ran out of room. The D: drive is where we have all the extra space and where the web directories are supposed to be.

So, we moved all files that had changed since we first copied them to the new server by hand, then grabbed only the settings and MIME types for each domain. We soon found it failed after migrating only a couple of domains, giving only an error number (per Microsoft’s usual SOP). After some trial and error, we discovered the problems were coming from sites with Front Page Extensions enabled; while we were prepared to recreate the FP Extensions by hand per the migration tool docs, we didn’t expect FP sites to fail outright. So we moved everyone but the FP sites, and then did the FP sites in several small batches. Moving one or two FP sites at a time worked, but any more than that and it failed.

Furthermore, the migration tool didn’t migrate FTP sites. For the customers with FTP sites, we had to recreate each of those by hand, just as we had to do with the Front Page sites. Finally, we discovered that the sites we migrated without using the Content option weren’t working; it turns out IIS wanted to see the web data in the web directory on the C: drive. On the sites we did migrate the data for, we found duplicate data on the C: drive. So, we had to go through (by hand again) and redirect the Home Directory for each site to the appropriate location on the D: drive.

In the end, we might as well have recreated each site by hand to begin with, especially after having to recreate each user by hand as we weren’t aware of a user migration utility and are not using Active Directory or even PDCs on this network. An expected 1-2 hour project turned into a 5-hour ordeal followed by more time the following Monday recreating the Front Page and FTP sites (we only recreated a handful that night for the known active users/udpaters).

There may be a Windows admin or two among you chuckling that there may have been an easier way to accomplish this, and I’d love to know what it is. But, given our research has yielded little else, I’m betting it’s still not going to be as easy as the Unix side. Creating a tarball, moving it, and unpacking it is about as easy as it gets.

Did we get the job done? Sure. But our downtime would have been significantly less with FreeBSD, and almost as important, our employer wouldn’t be kicking out as much overtime and we would have saved ourselves some heartburn. As a result, plans now are to host everything on FreeBSD, and we’ve already got an older server set aside for testing and evaluation some of the customers’ setups.

I waited several days before writing and posting this, hoping it wouldn’t come off as a long rant. I don’t know if I succeeded or not, but in an installation like mine, it’s becoming more and more apparent that there’s no advantage in keeping Windows around. Our other server is more or less held hostage by the fact our ISP billing software is only supported on Windows, but beyond that, Open Source fulfills our needs, is easier to manage, and will save us money (not only on licensing fees but on things like AV licenses, etc.).

Linux and Unix just plain rock.