Performing a Staged Exchange Migration To Office 365 (Exchange Online)

Introduction

It’s a fact that more and more organizations are making, or at least are considering making, the move from an on-premise messaging environment to Exchange Online (part of Office 365) in the foreseeable future. The migration path from an on-premise messaging environment to Exchange Online will differ based on things such as size of the on-premise environment, number of users, the messaging environment an organization is migrating from as well as the expectations revolving around coexistence.

So if we leave third party migration solutions out of the picture, we really have four different migration approaches at our disposal:

• Exchange Cutover migrations
• Staged Exchange migrations
• Hybrid Exchange Deployment-based migrations
• IMAP-based e-mail migrations

In this particular multi-part article series, I’ll go through the steps necessary to perform a staged Exchange migration to Office 365 (Exchange Online). The other migration approaches will be covered in another set of articles here on MSExchange.org.

Ok so the primary targets for a staged Exchange migration are medium organizations that wish to move mailboxes to Exchange Online over a period of time. With this migration approach, you configure simple coexistence (mail flow between Exchange on-prem and Exchange online as well as a shared global address list (GAL)). It’s worth noting that this migration model only supports Exchange 2003 and Exchange 2007 as source environments not Exchange 2010. In addition, it's worth noting the staged Exchange migration approach isn’t supported with Office 365 professional and small business plans.

To share the GAL in a staged Exchange migration scenario, you set up directory synchronization (DirSync) and if single sign-on (SSO) is required, you deploy Active directory Federation Services (ADFS) to achieve this. So unlike when using the Exchange Cutover migration approach, you set up ADFS and DirSync prior to performing the actual migration.

Note:If you require rich coexistence (free/busy & calendar sharing), MailTips integration (between Exchange Online & Exchange on-premise), Exchange Online-based online archiving support, mailbox offboarding functionality (move mailbox back to Exchange on-prem) as well as the option to manage Exchange Online users using the on-prem Exchange Management Console, you must use the hybrid Exchange deployment-based approach. With this approach you deploy one or more Exchange 2010 servers in your Exchange 2003 or Exchange 2007 on-premise environment and then configure coexistence using the Hybrid Configuration Wizard (HCW) that was introduced with Exchange 2010 Service Pack 2. I’ll cover this migration approach in another multi-part article series here on MSExchange.org in a not so distant future.

When performing a staged Exchange migration, the e-mail data is migrated to Exchange Online using the e-mail migration tool that lives inside the Exchange Online version of the Exchange Control Panel (ECP). This tool is based on the Outlook Anywhere (RPC over HTTPS) protocol so prior to beginning the migration, it’s vital that both autodiscover and Outlook Anywhere work properly in your Exchange on-prem environment.

Lastly, as most of you know, Office 365 not only consists of Exchange Online but also Lync Online and SharePoint Online. However in this article series we only focus on the Exchange side of things. Said in another way, the steps required to set up and “migrate” Lync Online and SharePoint Online are outside the scope of this article series.

Alrighty, let’s begin shall we?.

Creating an Office 365 Tenant

Okay so the very first thing we want to do is to create the Office 365 tenant. You can create a trial at http://www.office365.com. After having filled out the form and chosen an Office 365 tenant name, you receive an email containing the Office 365 portal link and other information such as tenant name, service plan and expiration date (Figure 1).

Figure 1: Office 365 Welcome Email

When you log on to the Office 365 portal, you are presented with the screen shown in Figure 2. Much like the Exchange Management Console (EMC), the Office 365 portal is split into four work centers (left pane): Setup,Management, Subscriptions and Support. You also see three or four links in the top of the page depending on whether you have been assigned an administrative role or not. Normal end users have the Home, Outlook and Team Site links while an administrator also has the Admin link.

Figure 2: Office 365 Portal

Adding a New Domain to O365

The very first thing we want to do in order to prepare for a migration of mailboxes to Exchange Online is to add our on-premise domain name (in this case “onpremise.dk”) to the Office 365 tenant. To add a domain to an Office 365 tenant, click “Domains” under the Management work center. On the “Domains” page, you see the default “domain.onmicrosoft.com” domain listed.

Figure 3: Domains section in Office 365 portal

Click “Add a domain” and then specify the domain you wish to add as shown in Figure 4 then click “Next”.

Figure 4: Specifying the domain you wish to add

Office 365 now needs to verify that you actually are the owner of this domain. This can be done using two methods. One is to add a TXT record to the public DNS server hosting your domain (recommended approach) and the other is to add an invalid MX record. In this article, we use the TXT record-based approach.

Figure 5: Instructions for verifying the added domain

To add a TXT record, logon to the DNS control panel at your DNS hosting provider then click ”Add TXT record” or whatever it's called in the web UI you’re using. The steps differ a bit from provider to provider, but basically, you need to add a host name and the ”Destination” for that host name as shown in Figure 6.

Figure 6: TXT record added in the DNS Control Panel at public DNS provider

After having added the TXT record go back to the Office 365 portal and click the ”Verify” button. Since it can take up to 72 hours for the TXT record to propagate throughout the DNS systems, you will most likely receive the error message shown in Figure 7. So now is a good time to have a break and do something else.

Figure 7: DNS verification for domain failed

When Office 365 can verify the domain successfully, you are taken to the page shown in Figure 8. Here you can specify which services you wish to use with the domain. Make sure you at least select ”Exchange Online” and then click ”Next”.

Figure 8: Specifying the services for which the domain is to be used

The domain has now been added to the Office 365 tenant and at this stage you can either select to ”Configure DNS settings” or click ”Close”. Since we do not want to direct SMTP traffic directly to Exchange Online or change the autodiscover DNS record yet, click ”Close”.

Figure 9: The domain has now been added to the Office 365 tenant

We’re taken back to the domain list, and here we can see the status for the domain has changed to ”Verified”.

Figure 10: Domain has been verified successfully

Installing and Configuring the Directory Synchronization Tool

The very first preparation step we want to complete before we concentrate on installing and configuring the DirSync tool on the domain member server in our on-premise environment is to activate DirSync for our Office 365 tenant. This can be done by logging on to the Office 365 portal followed by clicking on the “Users” and from here on “Set up” under “Directory Synchronization” in the top of the page.

Figure 1: Activating Directory Synchronization for an Office 365 tenant

The reason why I want you to get that done as the very first step is because once you click that ”Activate” button, it can take up to 24 hours before the activation itself occurs! As you can see in Figure 2, the synchronization is in an ”being activated” state. In the past this step didn’t take more that around 15 minutes, but the aggressiveness of the scripts that activates DirSync for Office 365 tenants has been lowered signicantly, which makes sense in a multi-tenant environment like Office 365 hosting millions of users.

Figure 2: Directory Synchronization is being activated

By the way you can ignore the warning message that is received when clicking on the ”Activate” button (Figure 3) since this is a brand new Office 365 trial tenant that hasn’t had objects synchronized using DirSync yet.

Figure 3: Warning message when activating directory synchronization

When DirSync has been activated, you can see the status message is changed as shown in Figure 4.

Figure 4: Directory Synchronization has been activated for the Office 365 tenant

While we wait for DirSync to be activated for our Office 365 tenant, let’s log on to the domain member server on which we want to install the DirSync tool. From the server open the Office 365 portal and then click ”Users” followed by clicking ”Set up” under Active Directory Synchronization. In ”Step 4” download the relevant version of the DirSync tool.

If you launch setup for the DirSync tool immediately, you will see an error message stating that the tool requires .Net Framework 3.5 SP1 installed on the respective server.

Figure 5: .NET Framework 3.5 SP1 is required by the DirSync tool

We can install the framework using the ”Add Features Wizard” in the “Server Manager” or by downloading the full .NET Framework 3.5.1 SP1 package here.

Figure 6: Installing .NET Framework 3.5.1 using the Server Manager.

Important:
If you installed the .NET Framework 3.5.1 component using the Server Manager also make sure you update the .NET Framework component with the cumulative .NET Framework 3.5.1 Service Pack 1 update, which can be downloadedhere. In addition no matter which method you use to install it, it’s important you also install an SP1 specific update that fixes issues contained in SP1. You can grab that update here.

When you have installed .NET Framework 3.5.1 SP1 plus the important update, you can launch the DirSync installer and you will be taken to the Setup Welcome page as shown in Figure 7.

Figure 7: DirSync tool Installer – Welcome Page

Click ”Next” then accept the EULA and click ”Next” again. On the ”Select Installation Folder” leave the defaults and click ”Next”.

Figure 8: Installation folder for the Dirsync tool

Now wait a few minutes while the tool components are being installed.

Figure 9: DirSync components are being installed

When the installation has complete, click ”Next”.

Figure 10: DirSync tool installation completed

Now before continuing go back to the Office 365 portal and verify DirSync has been activated. If/when it has, click ”Finish” to start the configuration wizard.

Figure 11: Starting the DirSync tool configuration wizard

When clicking ”Finish” you’re taken to the DirSync Configuration Wizard welcome page. Click ”Next”.

Figure 12: DirSync tool configuration wizard – welcome page

On the Microsoft Online Services page, enter the credentials for an account with administrative permissions to your Office 365 tenant and click “Next”.

Figure 13: Entering credentials for an administrative account in the Office 365 tenant

Similar to the previous page, now enter the credentials for an account with administrative permissions to the on-premise Active Directory forest and click “Next”.

Figure 14: Entering the credentials for an account with administrative permissions to the on-premise Active Directory

We’re now taken to the Exchange hybrid deployment page which is where you can check ”Enable Exchange hybrid deployment” in order to leverage features such as off-boarding mailboxes from Exchange Online to the on-premise Exchange environment as well as storing online archive mailboxes in Exchange Online. This requires at least one Exchange 2010 server in the source environment, which is why the page is greyed out. For staged Exchange migrations, we do not wish to enable Exchange hybrid deployment, so this is just fine. Click ”Next”.

Figure 15: Exchange hybrid deployment page

The DirSync installer will now configure the DirSync management agents that imports Active Directory user, contact and group objects to the Dirsync metaverse on the DirSync Server and from here exports them to the Office 365 tenant.

Figure 16: DirSync tool installer configures respective management agents etc.

When the Dirsync tool configuration has completed, click “Next”.

Figure 17: The DirSync tool configuration is complete

Make sure “Synchronize directories now" is selected and then click “Finish”.

Figure 18: Selecting to synchronize objects from Active Directory to Office 365

You will receive the warning shown in Figure 19 which includes a link to a TechNet page that explains how you can verify synchronization works properly. Click “OK”.

Figure 19: Warning message explaining how to verify synchronization is occurring properly

What I usually do is start by launching the Dirsync UI shell by navigating to “C:\Program Files\Microsoft Online Directory Sync\SYNCBUS\Synchronization Service\UIShell” and double-click on “miisclient” as shown in Figure 20.

Figure 20: Launching the MIIS client

In the “Synchronization Service Manager on DIRSYNC” console, you can see the status for the last run of each management agent. You can also see the number of added, updated and deleted objects etc

If you have a bit of MIIS/ILM/FIM experience this is the place you want to verify synchronization is running as expected.

Figure 21: Synchronization Service Manager on DIRSYNC console

Besides the Synchronization Service Manager on DIRSYNC console, you can also look in the Application log. Here you can see event IDs that can give you a quick indication of the health state for the directory synchronization.

Figure 22: Directory Synchronization related event IDs in the Application log

Finally, we can check the Office 365 portal for when the last directory synchronization occurred (Figure 23).

Figure 23: Checking the time for the last synchronization in the Office 365 portal

You can also try to update a few attributes for a couple of users and see if the change is reflected on the Office 365 user. To force a synchronization, see the next section.

Forcing a Directory Synchronization

Since delta synchronizations from your on-premise Active Directory forest to Office 365 are scheduled to run every 3 hours, there may be situations where you want to force a synchronization. This can be done using the “Start-OnlineCoexistenceSync” cmdlet. But in order to run this cmdlet, you must first launch a Windows Powershell 2.0 console on the server and then navigate to “C:\Program Files\Microsoft Online Directory Sync” folder and from here run the “DirSyncConfigshell.psc1” script.

Figure 24: Windows Powershell 2.0 console

This will open another Windows Powershell console where you can enter the “Start-OnlineCoexistenceSync” cmdlet. Doing so will immediately force a synchronization.

Figure 25: Running the Start-OnlineCoexistenceSync cmdlet

Preparing the CSV File

Okay now that we have Directory Synchronization in place, we are ready to create a list (CSV file) containing the first batch of users we wish to migrate to Exchange Online.

The E-Mail Migration tool within the Exchange Control Panel (ECP) expects this CSV file to be formatted in a specific way. The CSV file must use comma separation and the following attributes are supported in the header row:

• EmailAddress which specifies the SMTP e-mail address associated with the respective on-premises mailbox. Bear mind this attribute is required.
• Password is the password that will we want to set on the Exchange Online mailbox. Password restrictions that have been configured for the Office 365 tenant applies to the passwords included in the CSV file. Bear in mind this attribute is optional.
• ForceChangePassword specifies whether a user must change the password the first time they sign in to their new Exchange Online mailbox. You can use “True” or “False” for the value of this parameter. Bear in mind this attribute is optional. It’s also important to note that if ADFS-based SSO has been deployed, this attribute must be set to “False”.

Lastly the CSV file must not contain more than 1000 rows.

In Figure 1 below you can see the CSV file we will use in this article series. It includes six mailbox users that we wish to migrate to Exchange Online.

Figure 1: CSV File with users to be migrated

Launching the E-Mail Migration Tool

With the CSV file prepared, we can move to the next step which is to launch the ”E-Mail Migration” tool from within the ECP. To do so, open the Office 365 Portal as a Global Administrator and then click ”Outlook” in the top of the screen (or ”Manage” right under the Exchange section in the middle pane).

You now see the mailbox of the logged on user. Click ”Options” in the top right corner and then select ”See All Options” in the drop-down menu as shown in Figure 2.

Figure 2: Opening the options (ECP) page in OWA

On the ”Options” page aka the Exchange Control Panel (ECP), click on ”Manage Your Organization” shortcut in the lower right corner as shown in ”Figure 3”.

Figure 3: Clicking manage your organization in ECP

Under ”Users & Groups” click the ”E-Mail Migration” tab (Figure 4).

Figure 4: E-Mail Migration tool within ECP

This is where all the magic happens. Click ”New” and in the new ”E-Mail Migration” window that appears, enter the e-mail address of the administrative account you want to use to migrate mailboxes from the on-prem Exchange environment to Exchange Online.

It’s important to note that the administrative account that will be used to migrate mailboxes from Exchange on-prem to Exchange Online must have the necessary permissions to do so. More specifically you must assign full access permissions to all mailboxes that are to be migrated or set Receive As permissions on the mailbox database(s) containing the mailboxes. For steps on how to assign the necessary permissions see this link.

Figure 5: Entering the email address and credentials for the administrative migration account

The E-Mail migration tool will now test whether it can access the Exchange on-prem environment using the Outlook Anywhere protocol (RPC over HTTPS).

Figure 6: Outlook Anywhere connection to the on-prem environment is tested

On the next page we need to specify the CSV file containing the users that are to be migrated to Exchange Online. Do so then give the batch job a name and click “Next”.

Note:
After the migration has completed, the default global administrator for the Office 365 tenant will receive an email with a migration status report. If you wish to have another administrator receive the report as well, you can specify one as shown in Figure 7.

Figure 7: Specifying who to migrate to

The migration batch will now be created and the content of the CSV file will be validated. If there are validation errors, you will get a warning and be able to click details in order to see what content is invalid as shown in Figure 8.

Figure 8: The Migration batch contains errors

In this specific case one of the users listed in the CSV file was listed with an e-mail address that didn’t exist in Exchange Online. More specifically, the email address for this user is ”FNorthup@onpremise.dk” not ”FNorthrup@onpremise.dk”.

Figure 9: E-Mail address doesn’t exist in Exchange Online

Okay with the error corrected, we have created another batch job and things looks much better (Figure 10). Click ”Close”.

Figure 10: Migration batch created without validation errors

You can now see the batch job is in a status created. In order for it to begin migrating mailbox data, we must click ”Start”.

Figure 11: Migration Batch job in “Created” state

The batch job will now go into a ”Queued” status (Figure 12) and after a few minutes (depending on number of users included) change to a status ”Running” (Figure 13).

Figure 12: Migration job queued

Figure 13: Migration job running

To see per user details for the respective migration batch job, you can click “Open” in the lower right corner. On the per user details page, you can see an overview of which mailboxes are in progress and the items synced/skipped for each.

Figure 14: Per User Migration Details

When all mailboxes have been migrated the status for the batch job will change to “Synced”

Figure 15: All Mailboxes synced

This means that we now can delete the migration batch job by clicking on the delete icon.

Besides moving data from the on-prem mailboxes to the new mailbox that have been provisioned for each user in Exchange Online, the E-Mail migration tool will also configure e-mail forwarding for each on-prem mailbox. That is from now on all emails sent to the on-prem mailboxes will be forwarded to the new Exchange Online mailbox. Since the on-prem mailbox user isn’t converted to a mail user object, this is done by inserting the user@onpremise .onmicrosoft.com address in the targetAddress attribute field for each user as can be seen if looking at a user object with ADSIEdit.

Figure 16: Forwarding address inserted in targetAddress field for an on-prem mailbox user

Assign License to Migrated Users

So the first thing we want to do for the Exchange users we migrated to Exchange online back in part 3 is to assign an Exchange Online license to each of them. To do so, log on to the Office 365 portal using the global administrator account as shown in Figure 1.

Figure 1: Logging in to the Office 365 Portal

When logging on to the Office 365 portal, you will see a warning that says one or more users need an assigned license in order to retain an Exchange Online mailbox. In order to see which Office 365 users that had their mailbox migrated but hasn’t been activate, we can create a view that only list these respective users.

Click “New View”

Figure 2: Warning about unlicensed migrated users

Name the new view and then tick “Users with Exchange mailboxes or archives and no licenses”. Click “Save”.

Figure 3: Creating a new user view

Now select the new view in the drop-down menu (Figure 4).

Figure 4: Selecting the new user view

We now see the 6 users we migrated back in part 3 of this articles series. Tick all of them and click “Edit”.

Figure 5: List of unlicensed migrated users

Now tick “Exchange Online” and click “Next”.

Figure 6: Assigning an Exchange Online license to the migrated users

Click “Activate”.

Figure 7: Send results in email page

We have now been taken to the “Results” page, where we can click “Finish”.

Figure 8: Results page

The migrated users have now been assigned an Exchange Online license.

Verifying Migrated Users can Access their Exchange Online Mailbox

With the migrated users activated, let’s verify they can access their Exchange Online mailbox using Outlook Web App (OWA). To do so, open a browser and enter the direct URL used to access OWA (in this case: “mail.office365.com/onpremise.dk/owa”) or logon to the Office 365 Portal followed by clicking “Outlook”.

Figure 9: Logging into Office 365 Portal with a migrated user account

No matter whether you entered the URL for the Office 365 portal or OWA, you will now be asked to change the password for the Office 365 user as can be seen in Figure 10. Do so and click “Submit”.

Figure 10: Updating the password for the migrated user

We’re taken back to the login page and here we need to provide the new password.

Figure 11: Logging into the Office 365 Portal with the new password

We are now taken to the Office 365 Portal as it looks for a user with an Exchange Online license. Click “Outlook” in the top of the page.

Figure 12: Clicking on the Outlook link in the Office 365 Portal

The OWA language page where you can choose the language for OWA and the time zone appears. After you have selected the relevant language and time zone, click “OK”.

Figure 13: Specifying language and time zone for Outlook Web App (OWA)

The mailbox is now opened in OWA and you can see the email content that was migrated from the on-premise Exchange 2007 mailbox.

Figure 14: Migrated user’s mailbox opened via OWA

This verifies the user has been successfully activated and can access his Exchange Online mailbox.

Installing Office 365 Desktop Apps

After a migrated user has signed into the Office 365 portal, she should set up her computer to work ideally with Office 365. This is done by running the desktop application that can be downloaded from the Office 365 portal.

The desktop app installs important updates as well as the Microsoft Online Services Sign-In Assistant (MOS SIA) which provides the end user with sign-in capabilities to Office 365. Amongst other things, it installs client components that make it possible to use Outlook and Lync to authenticate against Office 365. It also improves the sign-in experience by making it possible for users not to re-enter their username and passwords.

To install the desktop application, the user must click “Set up now” after logging on to the Office 365 portal.

Figure 15: Clicking “Set up now” in Office 365 Portal

On the appearing page, click “Set up” under step 2 in the bottom of the page.

Figure 16: Launching the setup wizard for the Office 365 Desktop Application

You will most likely get a application security warning. Click “Run”.

Figure 17: Application security warning

The Office 365 desktop app will now be downloaded.

Figure 18: Downloading the Office 365 Desktop Application setup files

The user now has to specify his credentials and then click “Sign in”.

Figure 19: Specifying the migrated user’s Office 365 credentials

The desktop app setup wizard now checks the system configuration, which can take a minute or two.

Figure 20: Office 365 Desktop Application checking the system configuration

Now click “Continue” in order for the desktop application to install important updates.

Figure 21: Selecting the applications that should be updated

Accept the license agreement.

Figure 22: Office 365 Desktop Application License agreement

The installation and configuration process will now take place and when completed, the user needs to restart his computer.

Figure 23: Computer updated and configured and restart required

After the restart the desktop app setup wizard will launch and complete the configuration as shown in Figure 24.

Figure 24: Computer updated and configured successfully

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.

Important:
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 inFigure 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:

• LegacyExchangeDN
• Cloud Email Address (the tenantname.onmicrosoft.com one)
• On-Premise Email address (primary email address of the user)
• Mailbox GUID

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 “alias@tenantname.onmicrosoft.com“ 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.

Note: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

Connecting Other Exchange Clients to an Exchange Online Mailbox

So in part 5, after we converted the mailbox-enabled users to mail-enabled users, I showed you how easy it is to create a new Outlook profile on a domain-joined client machine located on the internal network with the help of the Outlook Auto Account Setup feature.

But how do you access your mailbox using other Exchange clients?

Outlook Anywhere on non-domain joined machines
For non-domain joined clients, the process is similar to a domain-joined Outlook client, that is you can configure the profile using the Outlook Auto Account Setup feature. You just need to manually enter your email address (not necessary to use the tenantname.onmicrosoft.com one) and password.

Figure 1: Configure Outlook profile on non-domain joined machine

Outlook Web App (OWA)
There are two methods you can use to access your mailbox using OWA. The first one is to go to the Office 365 Portal (either via the shortcut put on a machine when the Office 365 desktop app is installed or by opening a browser and type: http://portal.microsoftonline.com). From the Portal, click the Outlook link.

Figure 2: Accessing OWA via the Office 365 Portal

The other method is to open a browser and type “http://mail.office365.com” which takes you directly to your inbox.

Figure 3: Accessing OWA directly using mail.office365.com

Exchange ActiveSync (EAS)
If you have a newer mobile device that supports autodiscover, you can simply enter your email address (not necessary to use the tenantname.onmicrosoft.com one) and password and the device will setup an EAS device partnership and start applying any EAS policies and then synchronize the content of the Exchange Online mailbox. This works similar to when you configure an Outlook client using the Auto Account Setup functionality.

If the device doesn’t support autodiscover or you, for some other reason, want to configure an EAS profile manually, you can enter “m.outlook.com” in the Exchange server name field.

Outlook for MacWhen using Outlook for Mac, you need to enter the email address and username (domain)

Figure 4: Connecting to Exchange Online mailbox using Outlook for Mac

When you click “Add Account” you will, while the profile is configured, receive the following redirect warning which you can safely allow.

Figure 5: Redirection warning in Outlook for Mac

Since Outlook for Mac uses the Exchange Web Services (EWS) service to connect to Exchange, the server name field will differ a little from what you see in Outlook for PCs.

Figure 6: Outlook for Mac uses EWS to connect to Exchange

POP & IMAP-based Email Clients
For organizations that still need to support legacy protocols such as POP and IMAP, the good thing is that both of these are fully supported with Office 365. The server name you need to use when you set up a POP or IMAP account are different based on where the user’s mailbox is stored in Office 365. But fear not, it’s very simple for the user to find the server name he needs to use. This can be done by logging into the mailbox using OWA and from there going to the “Options” page.

Figure 7: Option page in OWA

Under “Account” > “My Account” there’s a link called “Settings for POP, IMAP, and SMTP access”. Click it and a window similar to the one shown in Figure 8 will pop up.

Figure 8: Information that can be used to set up POP, IMAP and SMTP

Creating an Autodiscover Record that points to Exchange Online

When all Exchange users have been migrated to Exchange Online, the autodiscover in your external DNS can be configured to point at Exchange Online instead of at the on-premise Exchange 2007 Client Access Server(s).

Instructions on how to do this can be found under “Domains” > “Domain Properties” > “DNS Settings” in the Office 365 Portal as shown in Figure 9.

Figure 9: Autodiscover and other DNS related information in the Office 365 Portal

As you can see you need to create a CNAME record that redirects autodiscover requests from “autodiscover.yourdomain.com” to “autodiscover.outlook.com”.

In my case I needed to create the CNAME record shown in Figure 10.

Figure 10: Autodiscover CNAME record

Important:Bear in mind that once you change the external autodiscover record, users that haven’t been migrated to Exchange Online won’t be able to use autodiscover to set up mail accounts and use autodiscover-based features in Outlook 2007/2010.

Configure MX Record to Point to Exchange Online

When all Exchange users, groups and contacts have been migrated to Exchange Online and any line of business (LOB) application, network devices etc in your on-premise messaging environment have been configured to point to Exchange Online, you can configure the MX record for your domain to point directly at Exchange Online. By doing so, messages sent to migrated Exchange users, groups and contacts will no longer be routed via the on-premise messaging environment. It’s important to understand that once you make the switch, any on-premise solution that inspects or manipulates email messages before they hit the users inbox or are sent by the users will stop working.

The MX record you need to use in order to route messages directly to Exchange Online can also be found in Figure 9. In my case I need to point it at “onpremise-dk.mail.eo.outlook.com”.

Figure 11: MX record changed to point at onpremise-dk.mail.eo.outlook.com

Decommisioning Exchange 2007 Servers

When all Exchange users, groups and contacts have been migrated to Exchange Online and have configured the MX record to point at Exchange Online, you can start decommissioning your on-premise Exchange 2007 servers.

Important:
Note that it’s a good idea to keep at least one Exchange 2007 server with the Hub Transport, Client Access and Mailbox server roles installed in the on-premise environment, so that you can still manage mail-specific attributes if required.