I’ve been slacking on the OCS-related blog material recently, and that’s mainly due to the projects I’ve been working on, one of which is currently wrapping up.  My main focus since October has been a couple of migration projects from customer’s previously running Lotus Notes into the shared BPOS cloud.

For a little background information on the BPOS offerings, basically with the help of a simple sign-in application running on a desktop a user can have full Outlook, Live Meeting, and SharePoint functionality with all of the backend systems being completely hosted and managed offsite by Microsoft.  From a user-end standpoint they can’t tell that their Exchange services are hosted offsite and not integrated directly onsite.  But on the back-end it takes a pretty fair amount of work to get everything connected and migrated over.

There are a few threads in the Microsoft Online Services discussion forums that briefly discuss the options for moving from a Lotus Notes platform up to BPOS, either directly or via an intermediary mail system.  I’ve completed projects using both scenarios as BPOS has moved from a beta to full release service and third-party vendors have updated their toolsets to support the new environment.

Quest Notes Migrator for Exchange

The first migration approach I took was the only available path at the time: a two-hop migration of Notes to a new Exchange 2007 deployment located on-site, followed by a second migration up to BPOS.  The first leg was accomplished by using Quest Software’s Notes Migrator for Exchange (NME) to perform a fairly standard Notes to Exchange migration on-site.  Notice I said ‘fairly standard’ as usually you don’t have to stand up a completely new Active Directory forest and Exchange deployment and then tear it back down again afterwards.

This was a complicated procedure with much overhead, but it left us two benefits in terms of flexibility: freedom of change control procedures when modifying the interim forest and the ability to delete the entire forest upon completion of the migration without leaving irreversible schema changes in a production forest.  That said, this approach added significant time to the deployment as almost everything had to be performed twice.  Since mail coexistence was not used and a weekend ‘big-bang’ approach was chosen there was no need to use the Notes Transporter, but simple PowerShell scripts were used to bulk create mailbox-enabled user accounts in the interim forest.  Mailbox data was brought over in multiple stages from Notes to Exchange using NME and then from Exchange to Exchange Online using the MSOL Migration Tools found under the migration section of the Administration Center.

Since then Quest started testing the ability to connect NME directly to mailboxes in BPOS to cut out that middle-man process of two migrations.  Here’s a recent press-release stating the support for Direct-to_BPOS migrations using NME: http://www.quest.com/newsroom/news-releases-show.aspx?contentid=8503.

So, I just used this new process to perform a migration of nearly 10x the amount of data in less time than the previous project by using this single-step direct migration approach with NME.  The time saved by not processing and moving mail data twice can drastically reduce the overall time frame in relation to the amount of mail data being migrated.  In a green-field mailbox approach with possibly just moving contacts or small amounts of calendar data this can accomplished over a single weekend, but if there is 100MB of mailbox data across thousands of mailboxes each then a pretty significant amount of time will be required in advance to pre-load data into BPOS.  Although you can use multiple migration consoles, load balanced Internet connections, etc there is still the very real impact of pushing gigabytes of data across a latency-happy public Internet.

The most recent version of the NME User Guide now has an additional section which outlines the order of migration steps.  Among these steps there is one important caveat that has not yet made it into the documentation: the Outlook profile for the ‘migration’ account must have Offline Cached Mode disabled.  Once the BPOS Services client configures the Outlook profile for the desired administrator account it cannot be left in cached mode.  If initial connection attempts to BPOS from NME were made while in cached mode any changes to will not be properly picked up, including the important Receive-As rights which will be granted on the back-end via a submitted service request.  The same error will appear before and after the change if still in cached mode:

To resolve this problem delete the Outlook profile and the .OST file.  Then open up the Sign-In client and authenticate with the same administrator account and access the Options tab. Select the More Options button and then click the trouble shooting link for “Reconfigure desktop applications” which will allow you to reconfigure Outlook and recreate the missing profile.

Immediately close Outlook and open the Mail control panel to select the profile and disable cached mode.  Make sure to delete the newly created .OST file again (which should be quite small if Outlook was closed as soon as it was configured).

Form this point NME should be able to connect to the BPOS directory without complaining about missing “Receive-As” permissions.