Migrating to Microsoft BPOS – Part II

In his last article, Johan gave us a crystal clear guide to preparing to migrate from an on-premises Exchange environment to a Cloud-based BPOS (Business Productivity Online Suite) environment. With the preparations complete, he now walks us through the final steps of the migration, and correctly configuring the environment.

In my previous article, we saw how to prepare our Exchange and (newly created) BPOS environments for a migration to Microsoft’s cloud-based business suite. By this stage, out BPOS environment is essentially ready, and we are almost at the stage where we can start the migration process. However, there are still some final preparations to go through on our local Exchange environment, which we’ll go through now.

Preparing for Mailbox Migration

Now that the users have been created in BPOS, it’s time to migrate their existing mailbox content to the BPOS environment. Microsoft provides a free tool, available in both 32-bit and 64-bit versions, which you can use to easily perform this migration from your on premise environment to BPOS. The tool can be downloaded by following the links below:

(Editor’s note: with the move to Office 365, these tools have been deprecated)

  • 32-bit Migration tool
  • 64-bit Migration tool

To migrate e-mail via a secure channel to BPOS, you may want to create a separate send connector, which  will need to be configured so that it will only be used when e-mail is sent to the BPOS domain (so, in our case, johanveldhuis.emea.microsoftonline.com). In addition to this, a 3rd party certificate needs to be assigned to the SMTP service, and will be used to setup a secure channel with the BPOS Exchange environment.

You may be wondering why we’re setting up a channel with the BPOS domain and not the real domain? If you recall, all users will now have two e-mail addresses, and one of them will be in the BPOS domain. Now, because our on-premise Exchange environment is currently authoritative for (in our example) the exchange-blog.nl domain, it will not, by default, forward e-mail to users who are not hosted on the on-premise Exchange Server. However, as the BPOS domain will be ultimately added to the user object of a migrated user, Exchange will be configured to forward the message to this new domain, instead of generating a Non-Deliver Report (NDR).
There are two ways to create a send connector to be used for migrating the mailbox content to BPOS:

  • Using the Exchange Management Console (EMC)
  • Using the Exchange Management Shell (EMS)

This connector will also be used during the coexistence phase to forward  messages to mailboxes which have already been migrated.

Using the Exchange Management Console

To create the send connector using the EMC, follow these steps:

  • Open the EMC;
  • Expand the  Organizational Managementnode;
  • Select the HUB  Transportnode;
  • Select the New Send Connectoroption in the Action menu;
  • Enter in a recognizable name, and choose Customas the type;
  • Add the BPOS name to the address space, in our case johanveldhuis.emea.microsoftonline.com;
  • Choose the Route mail through the following smart hostoption, and use the following fqdn: mail.global.frontbridge.com;
  • Leave the default authentication method (which is None) selected;
  • Accept the default settings on the Sourcepage;
  • Click the Newbutton to create the send connector.

Using the Exchange Management Shell

The second method, creating the Send Connector via the EMS, involves running the command below:

Let’s examine the command a little bit; to start with, name is obviously the name of the send connector. Using the addressspaces parameter, we can define which domain this send connector should be used for, and by specifying the smarthosts parameter, we can configure the send connector to deliver mail via a smart host instead of via DNS.

Once you’ve got the Send Connector set up, and the migration tool has been installed, you’re basically ready to start moving your content to BPOS.


Besides creating the send connector, depending on your situation, you might need to configure some security-related settings, such as firewall changes and permissions needed in the on-premise environment.


For the migration tools to work, they will need access to BPOS via a few ports which are laid out in the two tables below. For security reasons, you might decide to even limit this to only the IP addresses of BPOS.




Migrations tools


Migrations tools


mail routing


SMTP relay to BPOS using TLS

Table 1. Overview of used ports used by Exchange and the migration tools

Data Center

IP ranges

Primary North America VA3 (RED001)

Secondary North America WA4 (RED001)

Primary EMEA IE2 (RED002)

Secondary EMEA NL1 (RED002)

Primary APAC SG1 (RED003)

Secondary APAC HK1 (RED003)

Table 2. Overview of IP ranges used by the Data Centers

User permissions

As already mentioned, the user account we are using to perform the migration also needs the correct permissions to perform the migration. Firstly, to install the utility, the account needs to be a member of the local administrators group. Besides the permissions to install the utility, we will also need to have Exchange administrator permissions in the on-premise  Exchange environment In order to migrate the content.. Last, but not least, you will also need to have an administrator account in the BPOS environment.

Now that we know exactly what we need, we can have a look at how we can actually migrate the content from on-premise to BPOS.

Move Content from On-Premise to BPOS

To migrate the mailbox content to BPOS, we once again have two options available:

  • Export the old content to a PST using Outlook, and import it to BPOS
  • Migrate the content using the Migration Tools already offered by BPOS

The first option requires the user to export and import a PST when moving to BPOS. Clearly, this option may only be used in very small scenarios because it is a lot of work, depending on the size of the mailboxes involved.
On the other hand, the tool provided by Microsoft to migrate to BPOS can help you with several scenarios:

  • Migrating mailboxes from POP3 to BPOS
  • Migrating mailboxes from on-premise Exchange to BPOS
  • Migrating mailboxes from hosted Exchange to BPOS

In our example, we’ll have to use the second of these abilities and migrate our on-premise Exchange mailboxes to BPOS. However, the next question is “what does the tool migrate, and what does the tool not migrate?” In the table below is an overview of what the tool is able to transfer:

Will be migrated

Won’t be migrated


Auto-archive settings

Calendar items

Conditional formatting

Contact items

Content for shared folders (RSS feeds and shared subfolders)


Delegated access to user mailboxes and associated  Access Control Lists (ACLs)


Hidden messages




PST Files


Search folders and subfolders


User-customized mailbox rules



Table 3. What will and won’t be migrated by the Microsoft BPOS Migration Tool.

When opening the tool, you will get an overview of all the mailboxes which are hosted on your Exchange server:


Figure 1. On-premises overview

As you can see in figure 1 above, user Bill is hosted on our server, and his migration hasn’t been started yet. In the action menu of the tool, you have several options, one of which is to Migrate mailboxes. When you select this option, a wizard will be launched which has an Exchange 2007 look to it, and will guide you through the process of migrating content to BPOS. Once again, there are two options available to you (as seen in figure 2):

  • Copy the local mailbox content, which will copy all of the mailbox’s contents to BPOS
  • Do not copy the local mailbox content, which will configure e-mail forwarding so that e-mail which arrives in your on-premises mailboxes is then sent to your BPOS mailboxes

Most people will select the first option and, because our goal is to migrate to BPOS, so shall we. In the event that you don’t have an SSL certificate installed on your Exchange server, you need to select the Allow unsecured connection with source server option, which will allow all mailbox content to be migrated in plain text. If you want a more secure method, then you’ll need to install an SSL certificate as discussed earlier.


Figure 2. Migration options

Before the migration starts, the wizard will give an overview of the current size of the mailbox and also of the mailbox size allowed by BPOS. This latter value was configured when creating the user account in BPOS to prevent migration failures as the result of a too-small quota being set on the target mailbox.


Figure 3. Reviewing the mailbox size prior to the migration.

The next step is to select what content is to be migrated to BPOS. As you can see in figure 4 below, you have the opportunity to select the type of content as well as the date range, which is clearly useful if you only want to migrate content from, for example, the last year.

In terms of the actual migration process, a maximum of 10 threads is the default configuration of the migration too, so no more than 10 mailboxes can be migrated at one time.


Figure 4. Selecting exactly what content is to be migrated.

Before we will finally kick off the migration, a small overview is displayed showing the settings which will be used. If these settings are correct, then we can just press the Migratebutton to start the process.


Figure 5. Confirming that all the settings are correct.

You can monitor the migration during the process, although the information is not very detailed as you can see in the screenshot above.  Once the migration is completed you will see that the migration statusand forwardingvalues have changed in the main window of the BPOS migration tool (Figure 1). By default, the on-premises mailbox will not be deleted, but a forwarder will be configured on it. 

As already mentioned in the table earlier, the ACL’s won’t be migrated by the tool and, as a result, user permissions will need to be reconfigured on shared resources. Thankfully, permissions can easily be set using the Add-MsOnlineMailPermission PowerShell cmdlet, which is included with the Migration Tool. For example, say we want to grant user Bill full mailbox permissions on the support mailbox:

As you can see, we use a variable $cred which will store the credentials provided by the user. These credentials will need to be for an account which has administration permissions in BPOS.

Using the GrantFullAccess parameter, we can grant full mailbox access, and the default value of this parameter is false. In addition to the GrantFullAccess permission, the GrantSendAs parameter when set to true, allows the user gaining permissions to send mail as the user they are gaining privileges over. So, in our case, Bill can send e-mail using the support e-mail address.

That’s all well and good, but what if you will need to set permissions on multiple mailboxes? In that case, you can use a CSV file containing the mailboxes and correct permissions in conjunction with the Add-MsOnlineMailPermission cmdlet. The CSV will need to contain the following headers:

  • Identity
  • TrustedUser
  • GrantFullAccess
  • GrantSendAs

So, for example, say we want to give Bill full mailbox permissions and send-as permissions on the support mailbox, but another user, Joe, needs to have full mailbox permissions only. In that case the CSV will look like this:

Now that we have the CSV, we can use it as input for the Add-MsOnlineMailPermission cmdlet:

Just as in the earlier example, we will first retrieve the users’ credentials using the get-credentials cmdlet, and once we have those credentials we can import the CSV file and set the permissions. Once we have set the permissions, both users will have access to the support mailbox, but only Bill can send mail as the support mailbox (assuming both users are signed in as themselves, and not into the support mailbox directly, of course)
As a final step before cleaning up all the mailboxes on your Exchange server, it might be useful to reconfigure Outlook for each user, to prevent issues when removing the old mailboxes.

Once all users are migrated to BPOS, don’t forget to modify your autodiscover record so that it points to BPOS instead of your on-premise Exchange. If you forget to do this, it will lead to loss of functionality for users who already used Exchange 2007 in combination with Outlook 2007 or 2010.

Reconfiguring Outlook

To prevent users from needing to enter their password each time they want to use Outlook, you could install the Microsoft Online Services Sign In Application. Besides handling BPOS sign-in, this tool will also perform Single Sign One (SSO); it can configure Outlook and other applications, such as OCS, Live Meeting and SharePoint Online for a user, and give the user the ability to change his/her password  without having to logon to the company portal. The tool can be found on the company BPOS portal under the downloads tab:


Figure 6. Downloading the Microsoft Online Services Sign In Application.

Once installed, you can launch the utility and select which applications will need to be configured for you. In this scenario we will only configure Outlook (E-mail and Calendaring) and SharePoint Online (My Company Portal). When the configuration is completed it will look omething like figure 7below:


Figure 7. Successful auto-configuration of Microsoft Outlook and SharePoint Online.

Removing Local Mailboxes

Now that the email client has been reconfigured to use BPOS, it’s time to delete the local mailboxes which are still located on the on-premise Exchange server, which can also be done using the BPOS migration tool which we discussed earlier.

Just select the mailbox(es) which you would like to cleanup, and then select the delete local mailboxesoption in the menu on the right-hand side of the screen, and  this will launch a wizard to guide you through the process of removing a local mailbox. By default, deleted mailboxes will still be retained for 30 days before being actually deleted, although this might differ in your organization, so please ensure you’ve got a backup before deleting the mailboxes!

As discussed earlier, a forwarder (Send Connector) is configured on the migrated mailboxes, which will automatically forward e-mail to BPOS if it is sent to the on-premises Exchange server. As a result (and a potential  advantage of this setup), you could continue to use both an on-premise and BPOS Exchange beside each other if you wished.

After the mailbox has been removed, you will see that the user has moved from the mailboxcontainer in your on-premises Exchange environment to the contactcontainer, which can be found below the recipient configurationoption in the Exchange Management Console. When you now retrieve the properties of the user, and have a look at the e-mail addressestab, you will see that the user has two SMTP addresses:

  • One for the primary domain
  • One for the BPOS domain

Don’t modify these settings, because doing so will cause mail issues when running both on-premise and BPOS Exchange side-by-side.


Figure 8. Checking the users -mail addresses.

Updating your External DNS, and Final Configuration Changes

Once all of the users have been migrated to BPOS and Exchange has been decommissioned, You can think about removing this additional information from your users’ records, but doing so is not 100% necessary as it is only an additional address. However, assuming  you do want to remove these details, before you do so, some changes will need to be made to BPOS and your external DNS entries, which we’ll take a look at now.

My advice is to first configure BPOS to enable inbound messaging, as it may take several hours before the changes are actually applied (although this is only applicable for the inbound messaging settings), and you may as well get that process started as soon as possible. If you don’t make first configure BPOS, then when you initially update your DNS to point to your new messaging environment, all inbound mails will obviously be rejected.

To enable inbound messaging in BPOS, login to the administration portal and select the Domains option, which can be found on the Users tab. Before you can actually enable inbound messaging, you will first need to make BPOS authoritative for the domain, because your BPOS environment will be the mail server responsible for mail sent to your domain.


Figure 9. Setting up your BPOS environment to be Authoritative for your domain.

Click on the domain and enable the Authoritative option on the first tab, and then click the Save button. Next, open the properties of the domain again, select the inbound messaging tab, and press the Enable button.


Figure 10. Enabling the Inbound Messaging option in BPOS.

As mentioned earlier, it may take a while before the new configuration is actually applied, and it’s states can be easily tested by using telnet to send an sample e-mail:


Figure 11. Testing whether Inbound Messaging has been correctly configured.

As you can see from Figure 11., the configuration change has been applied; if it has not been, you will receive a “relay denied” error message.

Now that BPOS will accept our inbound mail, we can update the external DNS to point to our new environment . This might take a while to finish – up to a maximum of 48 hours, depending on the TTL settings on your DNS records. Bear in mind when looking at your MX records in your external DNS that you might have several records. In most cases, one will have the lowest preference number (or rather, the highest priority), and that will point to your on-premise Exchange, and one will be the fallback MX record, which might be your provider (for example, your hosting provider).

To change the mail flow to point directly to BPOS, you will need to change the MX record with the lowest priority. This MX record will need to point to Mail.Global.FrontBridge.comwhich is the mail server for BPOS. Once you’ve updated the MX record, you can use nslookup to check if record has been changed:


Figure 12. Updating your MX records

As you can see, the MX record with preference 10 now points to BPOS. Now that no e-mail is being delivered to our on-premise Exchange environment, it’s time to decommission Exchange. This process is far out of scope for this article, so I recommend that you read the following Microsoft Knowledgebase article which describes how you can remove Exchange 2007.


By this stage, if you’ve also read the previous part of this article series, you should have everything you need to migrate from an on-premise Exchange environment to BPOS. This is not to say that you should migrate, because, as you have seen, BPOS has its own advantages and disadvantages, so you will have to think twice about which environment is right for your organization. The migration process to BPOS is time consuming, but not very difficult (at least, I never found it to be tricky). I hope you found this guide useful, and if you’ve got questions about what has been covered, then please feel free to contact me.