If you saw the original drafts of my last two posts that I stupidly put online, Working with SBS 2008, Part 1- Single-Server Migration and Working With SBS 2008, Part 2- Answer files and the installation, you know I tried doing a Swing migration on my "old" SBS 2008 beta box.  Didn't work.  But I still got my server migrated, though the swing was a complete bust.

There were three things I needed migrated:  My user profile on my workstation, my email and my Sharepoint site (which only had a few items in it as a test).  There were some other files on the server I wanted saved but those were trivial to deal with.

The profile was the easiest.  I used the Windows User State Migration Tool (USMT) Version 3.0.1.  It's the command-line scriptable counterpart to the Windows migration wizard included in Vista and XP.  It was easier yet to save the profile when I stopped trying to websurf on the machine while USMT was running!

Sharepoint 3.0 is backed up via the Sharepoint Site Administration page.  Wish I could say how the restore went but I accidentally deleted the backup files.

An obstacle I ran into was the backup volume on the old server.  SBS 2008 uses disk-based backup and configures a volume with a VHD file, the same format as Virtual Server and Virtual PC(though the VHD has no boot sector and cannot be used for virtual-to-physical migrations.) 

You can open the disk, extract the VHD and use vhdmount from Virtual Server to access the files I wanted to restore, but I really wanted my new copy of SBS to recognize the restore volume and use it to restore applications under Windows, much as the System Restore feature of the Server 2008/Vista install disk lets you mount your backup disk and restore from it. 

Apparently, Windows Server Backup doesn't do that, so it's vhdmount for me.  I used that on the new SBS machine to extract the Exchange databases from the old backup, which are in the directory c:\program files\microsoft exchange\mailbox\first storage group\mailbox database.edb.

This is where I ran into a wall:  I copied the mailbox directory to a temp directory and ran the Exchange Troubleshooting Assistant to create a Recovery Storage Group to hold the restored database and merge the mailboxes (only mine!) into the new database.

This is what happened instead:

Log Name:      Application
Source:        MSExchangeIS
Date:          6/3/2008 8:47:28 AM
Event ID:      1088
Task Category: General
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      SLAPPY.dmproductions.local
Description:
The information store could not be loaded because the distinguished name (DN) /O=[a different site name for the SBS beta]/OU=EXCHANGE ADMINISTRATIVE GROUP (FYDIBOHF23SPDLT)/CN=RECIPIENTS/CN= of message database "Recovery Storage Group\Mailbox Database" does not match the DN of directory /O=FIRST ORGANIZATION/OU=EXCHANGE ADMINISTRATIVE GROUP (FYDIBOHF23SPDLT)/CN=RECIPIENTS/CN=.

The database may have been restored to a computer that is in an organization or site different than the original database.

By design, I cannot mount the old database.  I made the conclusion only after many contortions where I ran eseutil with many different options, thinking the database was corrupted.  It likely was not;  I just couldn't do anything with it.

Nice thinking by the SBS team, and that is not sarcasm.  MS product managers are adamant that one cannot use beta code for production nor can one expect to migrate between betas or between betas and release candidates.  This is the first time I've ever seen it enforced in a database!

I did have a PST file for backup, but because I forgot a checkbox when saving my mail, I only had an older copy from two months ago.   Annoying--I did do my business with the Salem Commission on Disabilities via email, but not a big disaster for me. 

This migration was a migraine, and I'm bitterly disappointed I could not do a Swing.  But, SBS 2008 runs fine and when RC1 comes, I will have forgotten this.

I'm moving on.