Performing a Staged Exchange Migration To Office 365 (Exchange Online) – (Part 6)

If you would like to read the other parts in this article series please go to:

Introduction

In part 5 of this multi-part articles series revolving around staged Exchange migrations to Office 365 or more precisely Exchange Online, we converted the on-premise mailbox for each of the migrated users to a mail user object followed by creating a new Outlook profile for these users. Lastly we will verified that users that have been migrated could connect to their Exchange Online mailbox using Outlook.

In this part 6 which is the last part in this article series, we will continue where we left off in part 5. First, we will talk about how to access an Exchange Online mailbox using other Exchange clients than the Outlook client. Then we will create an autodiscover DNS record that points to Exchange Online. Moreover, we will configure the MX record to point at Exchange Online so mail going to our SMTP domain are routed directly to Exchange Online instead of via the on-prem Exchange environment. Finally, we will talk about decommisioning on-premise Exchange servers.

Let’s get started…

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 Mac
When 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.

To decommission Exchange 2007 servers please follow the instructions on this page.

This concludes part 6 of this article series revolving around how you perform a staged Exchange migration from an Exchange on-premise environment to Exchange Online and also ends this series. Hope you found it interesting and that you learned something new along the way.

1 thought on “Performing a Staged Exchange Migration To Office 365 (Exchange Online) – (Part 6)”

  1. Hi,

    This procedure is valid for exchange 2010 SP2 ?

    We had 1 root domain with default user and an OU with another email UPN suffix added to Domain and Trust for that requeriment. And child sub domain that host subdomain.rootdomain.com.ar but UPN suffix is different.

    I need to migrate root email + UPN suffix email (another domain within en OU) and accounts from sub domain (that had an AD server dedicated) and also UPN suffix diffier from the name of own subdomain.

    Can i use cutover or need hybrid transition like you explain in this article but with variants ?

    Can u send to me a link with any procedure ?

    Specially like your job, detailed. and special attention to SSL certificate, we actually have AD CA root certificate. Works very good, OWA and Mobile Devices, Outlook Anywhere, and not domain joined- PCs. Its Not from public entity like GoDaddy..Verisignt etc.

    And need to know how can i configure or reconfigure clients, and more important mobile devices with android.

    Thanks a lot. Very powerfull article and explanations.

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top