SBS Migration hell
I recently helped a friend with a swing migration from one (really old) SBS 2003 server to another (new) SBS 2003 server. As there is currently NO process provided by Microsoft to migrate SBS servers (at least none that I am aware of), my friend had purchased the SBS Swing It Kit, provided by Jeff Middleton (SBS MVP) to assist us in this project.

SBS (Small Business Server), if you haven't worked with it before, is designed for small businesses and is also designed to run on 1 server. As such, your 1 SBS server is set up to host many roles on the same box - we're talking Active Directory, Exchange, SQL, Sharepoint, and optionally, ISA and some others. There are license limits in place that only allow you to have a certain number of clients (I want to say 75?), which is why it should only be used for small businesses.

On to our experience. The SBS box in question was just running SBS Standard, which probably made it a "little" bit easier, but not much. A brief overview of the swing migration process is that you have to bring up a temporary DC, transfer everything to that, remove all references to the existing DC, then add your new server (which has the same name as the old server) back in. This by no means details all of the steps involved (which are quite numerous), so I'd encourage you to check out the Swing It kit previously mentioned if you have to go through this process. Anyways - adding the new server didn't pose any problems. AD and DNS replicated with no issues and we were able to do the things we needed. The problems began when we tried to add the new server (with the same name as the old one). We couldn't get AD to replicate. After a few hours of mucking around, we found the issue. Ready? It was the Windows Firewall service! Why on earth the Windows Firewall would decide to prevent Active Directory replication is beyond me, but it did. Once the service was disabled, replication took place within a few minutes and we could then proceed.

Probably the most difficult part about a migration like this is getting the Exchange data transferred. Luckily, as long as the server name (along with a few other things) is the same, you should be able to mount the database from the old server with no issues. I've done this several times for regular Exchange servers, and it's the method that you used to have to follow with Exchange 2000 (build recovery Exchange server in a new forest that has same name, same admin group, same database name, etc.). However, another catch was that there hadn't been a successful full backup in a few weeks, so there were LOTS of log files. To be on the safe side, we brought those over as well, even though the stores were in a clean shutdown state. The biggest nightmare for us was actually getting the stores to mount, though. Let me state for the record here that at 4am in the morning, patience is not my strong suit.

I had applied Exchange 2003 SP2 while I was still copying the databases and log files from the old server to the new one (hooked up old drive via USB 2.0 enclosure), and even though the stores were dismounted when I ran the SP, after it was done, it tried to mount the stores, and replay all the log files. This *obviously* wasn't going to work, as the databases didn't even exist yet! Anyways, to make a long story short, I killed the store.exe process so the SP install would finish. Once that was done, and the stores and logs were transferred, I tried to mount the stores, only to have it fail with some comical error about files not being in the right state, or some such nonsense. I re-transferred the databases and logs again, and verified the databases were still in a clean shutdown state (eseutil /mh), but no dice. Running out of time, I thought I'd try to re-run SP2 and see if something had gotten mucked up the last time. This time, like the last, it replayed all the log files, then it purged them (I don't think I've ever seen an SP purge log files - hehe). With that done, all I had to do was mark the databases as being able to be overwritten, then I was able to mount them successfully.

The other problem we encountered was with the migration of the shares. Because there was a lot of data in the user shares, we decided we didn't have enough time to move the data, so we hooked up the old hard drive into the new server, and re-created the shares. Though I could have sworn that we checked, apparently the new share for the User Shared Files (where My Documents gets redirected to) was set to share perms of Read only. Remember that Windows uses the most restrictive set of permissions when you are accessing a share, so even if you have full control at the NTFS level, if your share permissions are read-only, you aren't going to be writing anything to that share, bucko. That was easy enough to clear up.

Sooo - 12 hours, and a severe case of sleep-deprivation later, migration is done. A few minor problems cropped up later on, but my friend was able to take care of those.

My observations:
1. Why in the world does an SBS migration have to be this difficult?
2. Has anyone at Microsoft tried to migrate SBS servers? If so, do they expect small businesses to ever do this without hiring an sbs expert?
3. I don't like SBS. I really don't. Some people love it. I'm not one of them. It felt like a very dummified [1] version of Windows Server 2003, with wizards galore, and progress bars that leave no indication of what exactly it is doing.

I've promised myself to never touch another SBS server, and above all to never do another SBS migration. I'll leave those to the SBS experts, something which I don't claim to be.

[1] I think I just made up a word.
- posted by Ben Winzenz @ 11:00 AM