Skip to content

Month: May 2011

How to Manually Migrate from BPOS to Office 365

UPDATE – 13/10/2011 – Before walking through the steps described below, please read all of the comments, particularly the guidance from Microsoft Online Services.

Unless you’ve been living under a rock, you’ve heard about Microsoft Office 365, which is Microsoft’s bundled offering of online versions of Exchange, SharePoint, Lync, and Office. In case you’re unaware, Lync is what was formerly known as Office Communication Server, combined with LiveMeeting.

The product packs quite a punch, and if you haven’t already, I would urge you to check it out, particularly if you’re a small business. The value proposition is extraordinary, and you can get out of the business of managing your infrastructure, and focus on your core business. What’s even more compelling is that if you can’t or don’t wish to move completely to cloud based services, you can still move those pieces that make sense (to me, email is a no brainer), and work in a hybrid model. Microsoft is the only online vendor that I’m aware of that can offer this hybrid approach.

As a relatively small company, we have been using hosted email for over a year now, in the form of BPOS, which is the previous version of Microsoft’s online offerings. As a partner, we’re very interested in moving to Office 365 as soon as possible, but the migration plan for current BPOS customers won’t begin until some time after the final release of Office 365. Given the compelling features in Office 365, we didn’t want to wait, so we figured out a way to migrate manually.

Now, by migrate, I’m referring explicitly to email. This article does not cover the migration of SharePoint content, but given that we didn’t have much content in SharePoint Online, this wasn’t going to be a problem for us. Also, because the two services are using two different identity types, you can migrate your email now, and let the content get migrated later.

The secret to the manual migration is Outlook. Since Outlook 2010 can connect to multiple Exchange servers, it becomes the intermediary. This approach is very likely not suitable to large environments, and your mileage may vary, but it did work well for us.

1. Set up your Office 365 Account

No matter what domain you actually used with BPOS, there’s an underlying domain that you got when you signed up, that took the form and all users that you create can receive mail addressed to, no matter what domain that they are assigned to. Office 365 follows the same principle, except that the form of the domain is All users that will be migrating need to be created in the new Office 365 domain.

2. Login to the New Account

Normally, when a new account is set up in Office 365, the user is given a temparary password. This password is only good for logging into the main Office 365 portal and setting the users password – it won’t work for anything else, like Outlook access. Therefore, it will be necessary for you to log into to set the account password before continuing. (Note, don’t be confused by the domain – is the hub for Office 365 – the equivalent in BPOS is

3. Connect Outlook to Office 365

You don’t need the client integration tools to connect Outlook to Office 365, which is good, because at this point, we’re not ready to install them. We simply need to connect Outlook to the new server. First, from Outlook, click File – Add Account


Next, fill in your account information. Name, email, and password are all that you should need, but make sure that you use the right email address,


After you click next, you’ll be prompted for credentials – these are the credentials for the new account (, and you’ll enter the password from step 2 above. Outlook will then configure the account, and you should receive a success message. Once you do, click finish.

In order to continue, you’ll need to close, and restart Outlook. On restart, Outlook may prompt for the new profile, and after that, it will prompt for the credentials again. It does this because single sign on is not yet enabled for the new account. That will come later. Once credentials are given, Outlook will take a minute and set up the new mailbox. Once that’s complete, we’re ready to move on.

4. Move Mail Messages

When you start Outlook, you should now see at least 2 accounts in the folder pane, the BPOS account, and the new Office 365 account. Drag one of your folders from the BPOS account to the Office 365 node.


Repeat this process for all of your folders. When complete, open your inbox, select all if your messages (or all of the ones that you wish to migrate) and drag them to the inbox of the new account. This may take a few minutes, depending on the size of your inbox. Once done, repeat this for your sent items folder.

What happens is that the messages are moved locally on your system from the local cache of your BPOS account, to the local cache of your new Office 365 account. Then once that is complete, you can continue to use outlook as the accounts are synchronized in the background. This can take a significant amount of time, likely several hours depending on the size of your mail file, so plan accordingly. While synchronization is in process, the status bar will tell you, as you can see below.


5. Move your Calendar Entries

Calendar entries are a little bit trickier, because there’s no obvious way to select all calendar entries. In addition, the folder browser goes away when you select your calendar. It is however completely possible.

First, select calendar, and ensure that your BPOS calendar is the only one selected. Then, select the View tab, Click the Change View Button, and select List. This will present you with a list view of your calendar entries.


From the list view, simply drag all of the entries that you wish to migrate to the Office 365 calendar in the calendar pane.

6. Move Contacts, Tasks, and Notes

For each of Contacts, Tasks, and Notes, firs click on their heading, ensure that the BPOS account is selected, and drag them to their equivalent Office 365 account section.

7. Repeat As Necessary

Repeat steps 1-6 for all of the accounts that you wish to migrate. I know, I never said this approach would scale, but it works for us…..

This manual copy process can be carried out over a period of time. During this time, new mail will continue to be delivered to the BPOS account, so it will need to be manually moved again once the delivery changes, which is the next step.

8. Make DNS and Administrative Changes

As long as a domain is assigned to BPOS, you cannot assign it to Office 365. That’s why the user accounts on Office 365 have so far looked like Once the bulk of the mail has been moved, we are ready to decommission the domain from BPOS, and to assign it to Office 365.

Once complete, all new mail will be delivered to Office 365. However, because DNS changes are not instant, there may be a period of time where mail cannot be delivered. Mail may also continue to be delivered to the BPOS accounts for a period of time, which will work because BPOS only cares about the name portion of the email address. It is a good idea to perform this step during off-peak times.

In our experience, the BPOS had a little trouble letting go of the domain, and this led to delivery failures for the better part of a day. Try to do this during a period of low traffic, and don’t plan anything for the following day.

EDIT – JULY 2011


It appears that the glitches that happen at this point are more systematic that I had originally thought. The Forefront that is used by Microsoft Online will hang on to your domain until explicitly cleared. You will need to contact either Office 365 or BPOS support to get your domain flushed out. You will also need to de-associate your Office 365 users from your domain, so that you can also remove it from Office 365 and set it up again. You will have no mail for this period. In our case, this lasted for one day, but we were discovering the problem at the time. You should also note that the support staff that can make the required Forefront changes only work regular business hours, North American Central time, so plan accordingly.

If the domain gets stuck in Forefront, you will be able to send receive mail from within online services, send mail outside, but outside mail coming in will receive a relay error.

A) De-Associate All users from the main domain

You can’t remove a BPOS domain that is in use, so you will need to change the default domain for all users using it. You can replace it with any of your configured domains, but I would suggest re-adding them to the default domain,, which in the case of BPOS is

This is done from the BPOS admin console, Select Users, User List, and click on the the user that needs to be changed. from the edit user screen, simply change the Domain setting.

If one of the users that you’ll be changing is yourself, you’ll need to login with a different account that has administrative privileges. You can’t edit the domain setting of the user that is currently logged in.


B) Remove the domain from BPOS

Once all of the users have been de-associated, you can remove the domain. From the BPOS admin console, select Users, Domains. Select the domains that you wish to remove, and click the Delete button.


If the domain that you are removing is the default for your BPOS account, you’ll need to change the default first. You can’t remove the default domain.

C) Remove BPOS entries from your DNS records

In all likelihood, you’ll have 3 DNS records that are associated with your BPOS account. AN MX record for mail, a CNAME record for domain validation, and a CNAME record for autodiscovery. These records should be removed before proceeding.

D) Assign the domain to Office 365

From the Office 365 admin console, you can now add your domain to Office 365. Under management, click on Domains, and then Add A Domain. Follow the domain addition wizard. The first thing that you will need to do is to add a CNAME record to your DNS for validation purposes. Once that is complete, you will be routed to a page where you are instructed to make the rest of the changes to your DNS records.


Most of the records are fairly self explanatory. However, the server records can be tricky. I would caution you to stick to the recommended TTL values though. Our DNS provider ( has a rather open ended approach to SRV records, and it was not immediately obvious as to how to construct the records for Lync, given the instructions in Office 365.


Searching around a little, and hacking a lot, I finally came across a combination of values that work. I include them here in case anyone else runs across the same issue. Based on the entry form above, the values that I used were:

Host TTL Type Data
_sip._tls 60 SRV 1 100 443
_sipfederationtls._tcp 60 SRV 1 100 5061


E) Associate your users with the new domain

At this point, you should use the user management tool in Office 365 to set the users’ domain to the one just set up, much like you did when de-associating the users. Again, as with BPOS, you can’t change the domain property of the current logged in user, so it’s a good idea to create a generic admin account for this purpose.

If the DNS gods have been smiling, and you’re lucky, and it’s the right day of the week, email will be flowing. In reality, it’ll be a while before you can receive mail, but you should be able to send right away. In any event, you’re ready to reconfigure the users’ workstations.

9. Uninstall BPOS Components from User Machines

You’ll likely have at least one, and as many as 3 applications installed from BPOS. There’s the Single Sign on Client (pictured below), Office Communicator 2007, and Live Meeting 2007. It’s a good idea to uninstall all three from the client workstations.


10. Install the Office 365 Client Software

When the user logs into the Office 365 portal using their new ID (, they’ll see a Download link on the right side of the screen. From there, they’ll need to perform steps 2 and 3, Install Lync, and then configure the desktop. If they don’t already have Office 2010 installed, that should be done first. The desktop configuration tool sets up all of the desktop applications with the exception of Outlook.

11. Create New Outlook Profile

You could set up the new mailbox a number of ways, but given that the new account name will likely be the same as the old account name, I prefer to create a new mail profile for Outlook, set it as default, and configure it from scratch.

To do so, you’ll need to make sure that Outlook is not running, and then open up control panel. Within control panel, you’ll find an icon for Mail (32 bit). Open it.


You’ll first need to click on Show Profiles, and then the Add button, to create a new profile. You can name it whatever you like, but be sure to select it as the default profile for Outlook.


Then click OK. The control will close, so you’ll need to open it again. Once you do, click on the “Email Accounts” button, and configure the Office 365 account as described in the Office 365 documentation.

You’ll need to repeat steps 9 to 11 for all users that you need to migrate.

As I mentioned above, this a a pretty labour intensive way to accomplish a migration, but it does get you from A to B, and you can start using the features that make Office 365 so compelling. Given that UnlimitedViz is a partner, we really couldn’t afford to wait, and in the end, I’m really glad that we didn’t…


Access Denied When Accessing Search Service Application With Search Server Express 2010

Search Server Express is an excellent alternative to straight up SharePoint Foundation. It’s also free, but it gives you the fundamental underpinnings of the full SharePoint search infrastructure, plus a few other goodies. I’ve written about this previously here and here.

If you follow best practices for SharePoint deployment, and use a separate account for installing the bits and for the Farm account, you may run into a very odd little error. After everything is set up and you try to access the search administration application, you receive an access denied error. This happens even though the account that you’re logged in as is a Farm administrator, and a site collection administrator for the Central Administration site collection. If you log in as the farm account, all is well, but the actual administrator account is denied access.

To the best of my knowledge, this happens because of some oddness related to claims authentication. SharePoint properly applies the rights of the farm account, but not the setup account.

The fix for this is to properly add the NTLM authentication account for the required user into the User Policy for the Central Administration application. Unfortunately, unlike all other applications, you cannot change the User Policy for the Central Administration application through Central Administration itself.

You can, as with many other things however, do this through PowerShell.

I have shamelessly lifted the PowerShell script below from Tore Kristiansen at the Code Project.


$site = new-Object Microsoft.SharePoint.SPSite("")

$wa = $site.WebApplication

$user = "domainuser"

$policy = $wa.Policies.Add($user, $user)





In the above script, replace “” with the URL of your Central Administration site, and “domainuser” with your setup user account (or any other). After using this script, your service applications should become available.


Announcing the Premiere of The Data Queen

I’m happy to announce that a new UnlimitedViz blog went live today, The Data Queen. This blog is authored by Martina White who has over 10 years experience working with Business Intelligence products, originally Cognos, but for the past 6 years has been working exclusively with the Microsoft BI stack of products.

Martina is a cube designer extraordinaire and can form data into all kinds of informative shapes, hence the nickname. We’ve convinced her to start putting her techniques out in public, and this blog is the result. She’s already posted a couple of interesting articles, and there will be many more to come.

Have a look when you get a chance – it’s at

Leave a Comment

Election Mapping In The Cloud With Silverlight and Azure

I have been know to get involved with local politics from time to time. About 5 weeks ago, when a federal election was called here in Canada, I decided to build an application that would help local campaign scrutineers get their results in quickly and easily. Election night results and turnout information is notoriously difficult to collect and keep.

An election campaign in Canada is an interesting thing. It is essentially a company that is created, runs for 5 weeks, and then disappears. A cloud solution seemed to be the perfect answer.

I’ll talk more about the application in a future post, but once the application was built, it attracted the interest of one of the major media organizations in Canada, PostMedia. The only thing that they wanted added was mapping.

Another few days of work with the Bing Maps Silverlight control, and we had a couple of fairly interesting apps ready for public consumption. They’re currently available on the PostMedia website here:

and here:

Basically, you can see the results for the last two federal elections on a national basis, or on a poll by poll basis for individual ridings.

In case PostMedia removes these links after the current election, you can see the same applications here:

More later…

Leave a Comment