Moving or migrating Windows Small Business Server (SBS) has got to be one of the more wretched tasks of a Windows system admin. Moving servers is never fun, but SBS is especially bad.
You see, SBS is designed for up to 75 users on a single network and it’s designed to work alone. It’s the absolute center of the universe for its network — it’s the domain controller, Exchange Server, SQL Server, file and print server, fax server, everything.
And it’s a jealous mistress — you can’t have more than one on the network, or both of them flip out and shut down every 100 minutes. It’s King of the Domain, and it will tolerate no usurpers to the throne.
So having to move one of these installations to new hardware is a crappy place to be. What you need to do is get everything — files, email, databases, Active Directory installation (which is not a simple file copy; there’s serious replication voodoo involved), etc. — off one machine and onto a duplicate machine with the same IP, same name, etc., without ever having them both on the same network at one time.
I found myself in this spot a few weeks ago. Having utterly no idea where to start, I went to the Microsoft Support newsgroups and threw myself at the mercy of the Redmond Gods. Multiple responses came quickly: go to sbsmigration.com.
There I met a guy named Jeff Middleton who has developed a method called a “Swing Migration.” Jeff has apparently moved these machines a lot, and he’s documented a snazzy way to do it without killing yourself. It’s a series of server acrobatics to get around the fact that Microsoft hasn’t thought to include an “Export the Whole Friggin’ Server” wizard in SBS.
I bought Jeff’s kit, which consists of at least a thousand pages of documentation and dozens of scripts and utilities. It gets pretty staggering trying to move one of these machines since they do everything for a network, so the number of settings and files you have to recreate on the new server is insane. Thus, Jeff’s documentation had to cover every possible circumstance. I fully expected a section on “What To Do When Monkeys Fly Out Of Your Butt.”
Following the instructions, I was able to completely build the new server offline. I actually spent about two weeks on it. No prolonged, dramatic shutdown of the network, no all-nighter trying to get the new server online by morning — it was downright luxurious. And I didn’t have to manually duplicate anything. I had envisioned hours of setting up new user accounts and groups, copying permissions, etc. But there was none of that.
Then, last night, I shut all the workstations on the network down, and started loading data on a 300GB RAID tower. It took about two hours to get it all moved over to the new machine.
Moment of truth time: I pulled the network cable out of the old server and plugged it into the new server.
One by one I fired up workstations and logged on to find that…nothing had changed. The workstations had no idea they were talking to a new server. Exchange mailboxes, shared folders, shared printers — everything was the same. Every workstation had been utterly fooled into accepting the new server as the old one. It was brilliant.
(I’ll even admit to going and checking that the old server was indeed unplugged — it was that smooth of a transition.)
So this post is really just big “Thank You” to Jeff. He was a peach during the whole thing, he answered dozens of questions, and never responded with a curt RTFM, which I was fully expecting at any moment.
If you’re moving or migrating Small Business Server, hightail it over to sbsmigration.com. Your blood pressure with thank you.
(Note: Looking back over this post, it totally sounds like I’m shilling for Jeff. So let me state that I have no business relationship with him, and I get no commission or anything from sales. I’m just genuinely grateful for his help.)
(Another note: I’m pre-emptively closing comments here or else I promise this entry will be full of requests for SBS debugging assistance inside of a week.)