Intelligent Message Filter, Content Filter, can do more...

WinDeveloper IMF Tune
WinDeveloper IMF Tune

Migrating to Small Business Server 2003

Alexander Zammit

Alexander Zammit Photo

Alexander Zammit has been developing server applications for over 15 years. Most of his works involve Exchange integrated applications, including a FAX server, a mail security product and anti-spam products.

  • Published: May 23, 2006
  • Category: General
  • Votes: none - none
Cast your Vote
Poor Excellent

Migrating from SBS 2000 to SBS 2003 can be surprisingly difficult. The migration procedure supplied by Microsoft requires you to construct a completely new domain. Here is how this migration went about.

Recently I got involved in the migration of an SBS server. This required the upgrade of SBS 2000 to SBS 2003, transferring it to new hardware. Migrating SBS is not easy. A typical server houses the domain controller, DNS, Exchange, SharePoint, SQL and ISA. Thus the migration involves catering for various applications.

In general two main options are available. You either purchase a migration kit or else you use a combination of readily available migration tools. The availability of commercial solutions, reflect the fact that the second alternative is not easy. The commercial alternatives greatly simplify the migration process and are certainly worth checking.

In my case I went for the second option. Researching technologies is an integral part of my job and doing it the hard way has its own appeal! After going through all the process I have to say things went quite smooth. Nevertheless it was indeed complex and there are many things that could have gone wrong.

I started off by downloading the document Migrating from Small Business Server 2000 or Windows 2000 Server to Windows Small Business Server 2003 from Microsoft. I strongly recommend this document. It takes you step by step, from planning the migration, to installing the new SBS machine, to using the migration tools, and finally taking the new server live. It is very well worth reading it before starting the migration. It helps understanding the process and gives you an opportunity to take a final decision whether or not it's better to invest in a commercial migration kit.

This procedure does involve downtime. Also the various migration steps introduce areas where things could go wrong. The core part of the migration must be performed whilst no user is logged on to the network. Sacrificing a weekend sounds unavoidable to me.

I will not repeat the information provided by the document, but will just outline some of its salient points. This migration type requires you to construct a completely new domain. The domain and server names must be changed. In effect the server is re-constructed from scratch. The migration tools perform the job of re-creating the user accounts, transferring Exchange mailbox data and so fort.

One ramification of creating a new domain is the effect on user profiles at the client machines. The new domain introduces new user and machine accounts. Thus user profile settings associated with accounts from the previous domain become invalid, unless properly migrated. The Active Directory Migration Tool (ADMT) is the one responsible for re-creating user accounts and for the migration of user profiles at the client machines. This involves running a process on each of the client machines. Although in my case this worked well, this is often one of the most troublesome stages of these migrations.

Following the ADMT, Exchange mailboxes are migrated through the Exchange Migration Wizard. The wizard migrates the mailbox content, but does not migrate rules or public folders. These necessitate an extra export/import step. In my case most mailboxes were migrated fine except for one. In one particular mailbox some emails were missing! No errors where reported during the migration so this was not immediately apparent.

Once the issue was discovered, it turned out that the missing emails where generated by a custom application. This application generated emails by copying a template email. When the wizard performed the migration all but one of these emails (located in the Sent Items) were gone. My conclusion was that these emails where so similar that the Wizard filtered them. Recovering these emails involved the use of ExMerge to export and re-import the content of the entire mailbox.

Transferring SQL databases was the easiest part. It simply involved detaching the database from the source and attaching it to the destination server. Here SharePoint and ISA were not in use, simplifying our task further. In all cases the migration document does included details and links on how to migrate these applications.

The part of the migration requiring most work was logging on each of the client machines and fixing broken links. One application was also storing the old domain name and required re-configuration. We had to log on each of the 25 client machines and tweak these in turn. Nevertheless it was nice to see that all in all the ADMT did a fairly good job.

It is true that using a commercial migration kit would have saved us some time. Nevertheless the exercise was certainly interesting. I believe that your readiness to handle some downtime and to shoulder the pressure it may cause is the key to choosing the migration strategy to adopt. If you are about to perform such a migration, I hope this experience assists you in identifying the best way to proceed.

References

Migrating from Small Business Server 2000 or Windows 2000 Server to Windows Small Business Server 2003

Copyright © 2005 - 2016 All rights reserved. ExchangeInbox.com is not affiliated with Microsoft Corporation