MPECS Inc. Blog: Thoughts on Supporting SBS and SBS 2008 Migrations

Monday, 9 March 2009

Thoughts on Supporting SBS and SBS 2008 Migrations

Up to now, a large part of the product focus for us has been learning the SBS 2008 product and its various components and abilities.

We are now in a position where we need to accomplish some SBS 2008 migrations from existing SBS 2003 domains for us and for some of our clients.

One of the most important aspects of gearing up for a migration is for us to run through the migration virtually first.

The general sentiment in the SBS community when it came to installing SBS 2003 and now SBS 2008 for anyone contemplating going on to support SBS was to install SBS at least three (3) times before embarking on that endeavour.

Why?

The simple answer is, how can we hope to support a product we know little or nothing about?

SBS is a pretty complicated product that Microsoft has taken great pains to bring all of the component parts together and make them play nicely in the same sandbox.

And they do play very nicely in the same sandbox! :)

Now, once we have run the practice installs a number of times, the next step in the process is to get familiar with how to bring SBS back from the dead.

Disaster Recovery skills are a prerequisite in our industry. We must take the time to get to know the backup and recovery processes that are built into the SBS products, but also get familiar with some third party products that can help us along the way too.

It is very disappointing to encounter a dead SBS situation where the individual, technician, or whomever has been supporting that small business’ network has not performed any kind of test recovery on the client’s backup solution previously.

OUCH!

There is simply no excuse for a “professional” I.T. services provider single man shop or organization with a number of technicians to have not tested their client’s backups.

The new SBS 2008 product comes with quite extensive migration documentation that Microsoft has put together for us. The documentation has room to grow yet, but it is still very good at providing the foundation we need to go forward and migrate an existing SBS 2003 network to a new SBS 2008 box.

Now that we have passed about 4 months since the SBS 2008 product’s release, there is a good foundation of knowledge out there on SBS 2008 along with some additional directions to take with regards to SBS 2008 migrations.

Ultimately, experience with both SBS 2008 and SBS 2003 products will be the single most important factor for performing a successful SBS 2003 to SBS 2008 migration.

We cannot emphasize enough that any SBS migration project should be tested virtually first.

Here are some suggestions based on how we are proceeding with our SBS 2003 to SBS 2008 migrations:

Snapshot the SBS 2003 box before touching it for the actual migration. Put that snapshot away. Have a fallback in place in case things go awry.
There are awesome imaging products available to get a snapshot of that existing client SBS server that can be used to swing into a VM.
On the SBS VM, reset the user account’s passwords and make sure the POP3Connector service is disabled if the VM will be given Internet access.
Test the user accounts for access to their mailboxes.
Optional step: Snapshot one of the local workstations and restore it to a VM on the same virtual network as the now virtualized SBS 2003 VM.
Once both VMs are confirmed to be communicating with each other properly and the user accounts are fully functional, shut them down and copy those VHDs to have a backup of the configuration. A snapshot will do, but having those VHDs is good insurance.
Install SBS 2008 in Migration Mode and run through the migration steps.
Install SBS 2008 in Migration Mode and run through the migration steps.
Install SBS 2008 in Migration Mode and run through the migration steps.

No, the last two steps are not a typo.

Run through the migration process at least three times for the first time through a migration attempt! It is very important to get at least remotely comfortable with the process as it is very complicated.

Having some familiarity with how the process works with the specific client servers and a workstation will improve the chances of a successful migration immensely.

After running through the process three times, and subsequently the actual migration, then the rule of thumb should be to virtualize a client’s SBS 2003 and at least one workstation to do a practice run through before running the actual process on the client’s production environment.

Perhaps after running through a dozen or two SBS 2003 to SBS 2008 migrations, the technician may be comfortable enough to run through the process without the trial run … maybe.

As soon as we introduce a Line of Business application or applications into the mix, we have a need for that practice run. Toss into the mix any number of third party AntiVirus, database, accounting, and other applications and we will soon discover that nothing will beat the knowledge gained in a run through.

The need for the practice run becomes all the more acute the longer the SBS 2003 box has been around, or if it was an in-place upgrade from SBS 2000 that was an in-place upgrade from SBS 4.x!

Don’t know the history of the SBS 2003 box? Client is not too sure either and the audit notes are few and far between if they exist at all? Then run through the process virtually first! Get to know that box’s behaviour during the migration process because there very well could be some problem what will not show itself until well into the process.

We used this rule of thumb when we were learning the Swing Migration developed by Jeff Middleton too. We ran through the process a number of times prior to running our first Swing to make sure we had a good grasp on the process.

Ultimately, there is no replacement for experience. None.

2 comments:

Anonymous said...: Lots of great information! Thanks for sharing it.; 09 March, 2009 13:44
Philip Elder Cluster MVP said...: Mike,

You are very welcome! :)

Philip; 09 March, 2009 13:50