A while ago I was asked to help a customer upgrade an aged Exchange 2000 installation to new hardware and Microsoft Small Business Server 2003 Standard Edition. My customer secured the new server loaded up with SBS 2003; my job was to integrate it into the existing AD (Active Directory) forest and move all the users’ e-mail into the new Exchange system.

If you’ve ever wanted to add SBS 2003 into an existing domain, you already know where this story is going. About 30 minutes into the initial stages of bringing the new server online, it struck me: SBS doesn’t like being added into an existing AD forest. If SBS is the primary domain controller, all is well. But we were trying to go the other way, and SBS complained loudly no matter what tack we took.

I found out, to my dismay, that you cannot simply promote the new SBS into the existing AD during setup. If you do, Exchange will not install correctly, and you’re down for the count. If you try after SBS finishes installing and Exchange is on the server, it’s too late; a new instance of AD is created, and never the twain shall meet.

Starting over from scratch wasn’t an option -- there were too many users, file shares, and printers to re-create. So after a bit of research, one of my guys came across a technique for installing a new SBS into an existing domain called a “swing migration.” At first glance it looked like so much AD mumbo jumbo, but after exhausting most other avenues (and about a case of Red Bull), I decided it was the only way we were going to make this work.

In a swing migration, you promote a temporary server into AD and install a replica of AD onto it. You then disconnect the temporary server from the network and bring the new server online with the same name as the server to be replaced. Through some AD tomfoolery, the new SBS server ends up with its own valid replica of AD and then takes over the role of the retiring Exchange server.

But where to find that temporary server? None of us wanted to lug another box out to the customer site. So I came up with an alternative plan: Install Microsoft Virtual PC on the new server and use it to run the temporary Windows server for the migration.

Virtual PC allowed us to host both the temporary AD replica and the new Exchange installation on a single server. Plus, we could do it off-site and work out the migration in our own office, which meant the customer could stay operational, none the wiser to just how much work this really turned out to be. The internal networking of Virtual PC provided the connectivity necessary to replicate the AD info to the new server. When the swing migration was complete, we finished installing SBS, and Exchange installed without a hitch.

Virtualization proved to be a real lifesaver for us, and not just because we didn’t have to carry extra hardware. It also meant we could keep backups of the disk image. If we “broke” something along the way, no big deal, we just restored our disk image and started over. No sweat! Just hand me another Red Bull, please.