If you would like to read the other parts in this article series please go to:
In part 4 of this multi-part article series revolving around staged Exchange migrations to Office 365 or more precisely Exchange Online, we verified that the migrated users could log on to their mailbox using Outlook Web App (OWA). We then installed the Office 365 Desktop application so that the client computer were updated and configured appropriately to work with Office 365.
In this part 5, we will continue where we left off in part 4. First, we will convert the on-premise mailbox for each of the migrated users to a mail user object and then we will create a new Outlook profile for these users. Lastly we will verify that users that have been migrated can connect to their Exchange Online mailbox using Outlook.
Let’s get started…
Converting On-Premise Mailboxes to Mail User Objects
When using the staged Exchange migration approach in order to move your Exchange on-premise users to Exchange Online, you need to convert the on-premise Active Directory mailbox-enabled user objects to a mail-enabled user object. Why is this? Well as you probably recall from part 3 of this article series, when an Exchange on-premise mailbox user is migrated to Exchange Online, the E-Mail Migration tool configures forwarding for the on-premise user so that all email sent to the respective user’s on-premise mailbox is forwarded (via the targetAddress attribute) to the Exchange Online mailbox. This means that once the users are migrated they will no longer see new emails in the on-premise mailbox. In addition, Autodiscover still points to the on-premise Exchange organization and because you, with a stage Exchange migration, deal with a situation where some users haven’t been migrated to Exchange Online yet, you can’t point Autodiscover to Exchange Online as this will break autodiscover functionality for all users with an on-premise mailbox.
Because autodiscover points to the on-premise Exchange organization, when a user has his mailbox migrated to Exchange Online and opens Outlook from his computer, it will still connect to the on-premise mailbox even if he creates a new Outlook profile.
So how do I convert a mailbox-enabled user to a mail-enabled user Sherlock? Microsoft has created a script that does this for you. You can get it by following the download link in this article which also explains what happens under the hood when running the script. Actually, Microsoft has created two scripts, one that collects necessary information from the relevant Office 365 users and saves this in a CSV file. The other script uses the information contained in this CSV file to convert the on-premise AD user to a mail-enabled user object.
For details around what the script does, see the article I linked to. Also if you’re migrating from an Exchange 2003 based on-premise organization, you should follow the links in this article.
When you have downloaded the scripts (recommended you put them into the same folder that contains the CSV file for the particular batch of users you have migrated to Exchange Online), launch the Exchange Management Shell (EMS) with administrator permissions.
Figure 1: Placing scripts into the same folder that holds the CSV file used for the particular migration batch
In the EMS change to the folder holding the scripts and CSV file. Then run the “ExportO365UserInfo.ps1” script. You will be asked to enter the credentials of an Office 365 Administrator as shown in Figure 2 below.
Figure 2: Running the ExportO365USerInfo.ps1” script and specifying credentials for an Office 365 administrator
The script will now connect to Exchange Online for the respective Office 365 tenant and start collecting the required information for each of the users listed in the migration batch CSV file.
Figure 3: Script connects to Exchange Online for the respective Office 365 tenant and collects required information
The information will be collected in another CSV file named “Cloud.csv” located in the same folder as you can see in Figure 4.
Figure 4: Cloud CSV
If we open the “Cloud.csv” file, we can see the script has collected the following information for each user:
Cloud Email Address (the tenantname.onmicrosoft.com one)
On-Premise Email address (primary email address of the user)
Figure 5: Content of the Cloud.csv file
Now that the “Cloud.csv” file is in place, we can run the “Exchange2007MBtoMEU.ps1”, which is the script that will convert the mailbox-enabled AD object to a mail-enabled user object.
When you run it you must make sure you specify a domain controller you want to run it against as shown in Figure 6. When the script runs you can see the steps that are performed for each user object.
Figure 6: Converting mailbox user objects to mail user objects using the Exchange2007MBtoMEU.ps1 script
When the user objects has been converted, they will of course appear as Mail User objects in the Exchange Management tools. For instance, the objects will be listed under the Mail Contact node in the Exchange Management Console. Here you can also see the external email address is set to onpremise.onmicrosoft.com or whatever your default tenant domain name is.
Figure 7: Migrated users now listed under the Mail Contact node in the Exchange Management Console
Let’s now switch to the client machine for one of the migrated users and open the Outlook connection status window. Here we can see that Outlook still is connected to the on-premise mailbox.
Figure 8: Outlook connected to on-premise Exchange server
But next time Outlook does an autodiscover request or is restarted, the Outlook profile will be re-configured to point to the Exchange Online mailbox. This is Outlook, once an autodiscover request is initiated will be redirected to Exchange Online as the external email address of the (now) mail user objects points to the [email protected] email address for the respective user.
Figure 9: Outlook reconfigured profile to Exchange Online
Well then all is fine isn’t it? I mean Outlook has automatically reconfigured itself based on pure autodiscover magic and we are good to go right?
Unfortunately this isn’t the case… More specifically once you quit and restart Outlook, you will be faced with the dialog box shown in Figure 10 every time you start the Outlook client.
Figure 10: Dialog box when you do not create a new Outlook profile
Those of you who have performed Exchange dial-tone database restores probably recognize this dialog box. The reason why it pops up is because the OST file doesn’t match with the Exchange mailbox. In this case it’s because the user has been migrated from his on-premise mailbox to a new Exchange Online mailbox with another Mailbox GUID than the one associated with the on-premise mailbox. To fix this annoying issue, you need to create a new Outlook profile.
If the “Use Temporary Mailbox” is selected you will get access to the new Exchange Online mailbox and can see the migrated email data, but users would be prompted with this every time they start Outlook which we all agree isn’t ideal.
So let’s remove the current Outlook Profile and create a new one. We can do this by opening the “Control Panel” and from here “Mail”.
Figure 11: Opening Mail in the Control Panel
Remove the listed profile and then click “New”.
Figure 12: Remove existing profile
On the “Auto Account Setup” page, click “Next”.
Figure 13: Setting up a new Outlook profile
After a few seconds the profile will have been created.
Figure 14: Outlook profile created with success
Let’s tick “Manually configure server settings” in order to look at the Exchange Online configuration. Here we can see that the profile points to a server or more specifically a CAS array in Exchange Online.
Figure 15: servername (CAS array) configured for the mailbox
Now let’s click “More Settings” and then the “Connection” tab. Under the “Connection” tab click “Exchange Proxy Settings”. Here we can see the Outlook Anywhere configuration for the mailbox.
Figure 16: Outlook Anywhere configuration for the profile
Click “Cancel” twice and then “Finish” to exit the Outlook profile wizard.
Launch the Outlook client and the dialog box we saw with the old profile has disappeared and the user can now get up to speed with his Inbox.
Figure 17: Enter the credentials for the Office 365 user and tick “Remember my credentials”
First time Outlook is launched the user will be prompted for username and password. Let him enter is and also tell him to tick “Remember my credentials” so that the user no longer is asked for his credentials when Outlook is launched (unless the Office 365 password has expired).
Figure 18: Outlook connected to Exchange Online mailbox
This concludes part 5 of this article series revolving around how you perform a staged Exchange migration from an Exchange on-premise environment to Exchange Online. Expect to see part 6 published in a very near future.
If you would like to read the other parts in this article series please go to: