SBS2011–a post-Swing migration perspective

We just finished migrating one of our customers to SBS2011 Premium and I thought it might be worthwhile to share some of the experience with you.

This was not a simple migration a la SBS2008 –> SBS2011 or even a migration from SBS2003.  Rather, it was a migration from a standalone Server2003 DC with Exchange 2003 (all on a single physical box) into a two-server SBS 2011 Premium configuration running on top of VMware ESXi 4.1 U1.  Whew!!  Microsoft offers some migration paths and migration tools to go from older SBS installs into SBS2011 but they don’t offer a methodology to migrate from what our customer’s source system was; we had to find another way.  (As an aside, I have used the SBS2003 to SBS2008 migration tools and they work fairly well so I would assume the 2011 tools would be similar.)

I went back to the “well” and purchased a SwingIT kit from Jeff Middleton at sbsmigration.com.  Jeff’s kit was a mainstay in my toolbox back in the SBS2003 days and he has a kit for SBS2011 that allows for migrations such as the one we wanted to perform.  

Most companies that want to migrate to newer versions of SBS want to keep their domain and as much of their AD in place as is possible.  The SBS –> SBS (2003 –> 2008, 2003/2008 –> 2011) migration paths that Microsoft provides allow for that although some changes do have to be made such as the server name of the new SBS box.  This is all well and good but back in the day (2003) there was no good migration path offered by Microsoft so Jeff cooked up his “swing” methodology.  The basic tenets of the swing methodology are to leave the source server as intact and unchanged as possible (the ultimate fallback if migration fails); to use tools that allow the AD info to be migrated over to the new SBS server via a couple of interesting “hops” (the Swing); and for the new SBS server to maintain the same server name and identity as the original server even down to the share names thus allowing client machines to carry on as if nothing has really changed.

I’m not going to get into the in’s and out’s of the whole Swing process, for that info you have to purchase one of Jeff’s kits (hey, it’s only fair ….).  However, I can say that we followed his instructions faithfully and the end result was a working SBS2011 installation and a very happy customer.  But while I can’t get into too much of his process I can comment on some things that we discovered along the way.

Jeff’s process makes use of a temporary Windows server for a number of the Swing processes.  We used a Server 2003 VMware Workstation VM that was later moved onto the customer’s production ESXi server.  Because we were migrating into new servers that were also ESXi VM’s we were able to take advantage of the snapshot/rollback features of ESXi.  These features proved invaluable when we got ahead of ourselves and made assumptions and did NOT read the instructions completely for a given step of the Swing process (yes, we are men; no, we do not RTFM).  If you choose to purchase a SwingIT kit and will be performing a Swing migration you might want to consider working in a virtual environment as it will give you some flexibility you would not have otherwise.

To make a long story short, following Jeff’s processes we ended up with a properly functioning SBS2011 server with all the AD and user data intact.  Client machines on the domain had no problem finding the server and the published shares.  We did discover that we had to move objects in some custom OU’s into the predefined SBS OU’s for full SBS functionality to take effect (Jeff documents this to a degree but you will have to mess with things yourself).  We also discovered that SBS2011 does not like “hidden” shares (eg ShareName$ rather than ShareName); hidden shares do not show up in the RWA Shared Folders pane and also do not show up in the SBS management tools, they do show up in the “regular” Server 2008 R2 management tools.  We also discovered that Exchange mailbox migration takes its own sweet time, just as Jeff’s documentation suggests.  Be prepared to be frustrated by the rate at which the migration runs and the underlying speed of the servers really does not seem to make much of a difference.

The really nice thing about the Swing process was the fact that it gave us the time to take our time.  We actually took three weeks from start to finish and the customer only had about 12 hours downtime when we finally went on site with the new server (downtime being the time we had SMTP traffic stopped at the firewall while data moved to new server and Exchange mailbox migrations took place). 

I’m sure I’ll use the SwingIT kit again and again going forward and I can highly recommend this tool to anyone needing to perform a migration into SBS2011.