Cloud Computing: Migrating to Microsoft BPOS

To make the search  engines happy: “Migrating Microsoft Small Business Server Exchange Server to BPOS”. Note that I did a full migration; not an email co-existence (where some users are BPOS and others are local).

This turned out to be pretty much a no-brainer .. although in the process, I made it harder than it needed to be (not on purpose, of course).  Here’s the short story:

Original State:

• Microsoft Small Business Server 2000 (with Exchange 2000)
• Microsoft POP3 Connector collecting mail from an internet email server
• A mix of Windows XP and Windows 7 clients
• A mix of Microsoft Office 2003, 2007 and 2010

Final State:

• Exchange Online
• A mix of Windows XP and Windows 7 clients (upgrade work in-progress)
• (Mostly) Microsoft Office 2010

My biggest concerns:

• Avoiding mail interruption (MX record delays, profile confusion, etc.)
• Preventing loss of email content
• Migrating existing email to the online services

As I’d migrated my own (a much smaller) domain to the cloud a few months ago, I figured I had it cooked. However, I was wrong. My steps were:

• Create BPOS users and assign email services
• Cut the MX record away from my domain to BPOS
• Set up a second profile (pointing to BPOS) on each Outlook 2010 client
• Drag and drop old email between profiles in Outlook.

While this worked nicely (I have only five users on my domain), it was not optimal. I avoided email interruption and loss of email content, but I went to a much greater level of effort in the process. To my defense, Microsoft had not yet released the Exchange Email Migration Process document .. as it did not exist.

Sometimes it’s hell to be an early adopter. That said: Kudos to the team at MS who built the migration tool.

The correct (and easier) way? Well, start with a plan that includes:

• Users: User list, size of each mailbox, user (or workstation) availability during / after the migration. Depending on the size of your domain, be prepared to create logical groups you can migrate in succession. Suggestion: Prepare good communication and ensure user rights: to keep your hands off the workstations, your users must be able to install software on their local machines.
• Clients: I upgraded to Outlook 2010 as part of the migration; some before the migration, some after. Outlook 2003 and 2007 work just fine if you choose to remain on older versions. There appears to be no client-side difference as to when you do the upgrade.
• Schedule: Migration is simple, but it does take time. If executed properly, users will receive new emails immediately, but may not have access to older emails without incurring complexity on the workstation (i.e., accessing multiple profiles).
• Your availability: depending on the technical prowess of your users and the clarity of your instructions, you will have questions to address. Make sure you have time to work with your users and watch your migration process.

I’m serious: make a plan. To get you started (these steps can occur in parallel):

• With your LiveID, create your Microsoft Online Services account, identifying the services (and quantity of each) you want. You have an option of a 30-day trial before signing up for a one-year commitment. The full-meal deal is $10 / user / month. You’ll be asked to create an internal domain (something like yourdomain.microsoftonline.com) and an administrator account.
• In the Microsoft Online Services Administration Center, create your users and assign desired services to each. Have the creation process email you their initial (system-assigned) password.
• Ask your users to install the Microsoft Online Services Sign-in Client. This is a fairly simple process and a fast install. I asked my users to do the install but not the login, as I wanted to make sure everyone could get installed before wrapping myself up in loops that included system troubleshooting.
• Validate your MX record. While you’re at it, confirm you can access your domain registrar to make changes to it. The validation process is harmless; that is, it won’t make any changes to your email domain. However, you must confirm with BPOS that you can redirect the record when the time comes. It takes about a day to confirm. Microsoft has registrar-specific instructions on the Migration pane in the Microsoft Online Services Administration Center.
• Install Microsoft Online Services Migration Tools on a capable workstation (mine was pretty low-end). See the minimum requirements at Migration Tools Prerequisites. As the tool only migrations one email account at a time, you might try installing on more than one machine. The link to install is in the Microsoft Online Services Administration Center, under the ‘Migration’ tab.
• Confirm your Migration Tool can connect to your local Exchange Server.

When your MX record is validated AND your users have the Microsoft Online Services Sign-in Client installed AND you can connect to your local Exchange Server with the Migration Tools (the following steps can also occur in parallel):

• Edit each user in the Microsoft Online Services Administration Center, changing the domain from yourdomain.microsoftonline.com to yourdomain.com.
• Forward the system-assigned password instructions to your users (note: Microsoft could do a little better job of automating this, starting with a subject line that includes the user name), changing the domain name to yourdomain.com. Your users will sign in with the system-assigned password, changing it on their first login. When they do, the login client will set up a new Outlook profile with their full email address. Caveat: I don’t know what will happen if the current profile is named with full email address; mine were all ‘Outlook’. Possibility: if you create the users after you validate the MX record, you might be able to avoid the ‘changing the domain name’ step above. I didn’t.
• Warn your users: they will see an empty Inbox after the previous step.  Have them close Outlook and select their old profile until their migration is initiated. Once their individual mailbox migration is initiated, they should use the new profile instead of the old. Microsoft did a nice job of email forwarding for in-process mailbox migrations; mail is delivered to both profiles. Possibility: you may want to run migrations after COB, advising users to log onto their new profiles in the morning. This depends on the number of mailboxes you need to migrate, and the size (i.e., time required ) of each.

You’re now ready to go. The rest is actually simple:

• Update your MX record (instructions for this on the Migration tab in the Microsoft Online Services Administration Center). Email will go to the old Exchange location and be forwarded to the new until the record is propagated. Once email stops showing up in the old profiles, the MX record is moved.
• Run the Migration Tool, identifying the users you want to migrate.
• Advise the users to start using their new profile.
• Wait (bandwidth, mailbox size).
• Watch for errors; I had a few users with corrupt records. Start another user while dealing with these.

Once migration is complete (confirm this by email delivery to only the new profiles):

• Write your users with instructions on how to change their default profile to the new. You can avoid deleting the old (depending on your retention policies); the OST will persist until you remove it.
• Users will need to set up their email signatures; they can pull existing from their Sent Items folder.
• Shut down your local Exchange Server services; archiving per your local policies.

I managed to get all but one of the migrations without issue (record corruption errors I referenced above).  However, this was just in time for a service outage. Service outages happen; usually for only a few minutes.  During this time, the Outlook icon in the status bar will show a tiny hourglass, and your Outlook windows may freeze. Release this choked thread: mouse over the status bar icon, right-click and click ‘cancel server request’. Your mail windows will refresh so you can save drafts and documents.

You can check the status of the service in your region with the links below .. HOWEVER it requires a login (dumb). If login service is hosed, so is the ability to get service status:

• BPOS: Americas (NOAM)
• BPOS: Europe, the Middle East and Africa (EMEA)
• BPOS: Asia-Pacific (APAC)

Here’s what I saw tonight .. argh:

That said, the service is quite reliable, and I don’t need to manage my Exchange Servers anymore. Add to this the improved access to mobile and web clients, and you have a terrific commodity-based service you can share with your customers.