This full step-by-step guide is available as a PDF. Please click here to download!

Exchange Online Exchange Online is Exchange Server delivered as a cloud service hosted by Microsoft itself. It is built on the same technologies as on-premises Exchange Server, and offers essentially the same services as third-party providers which host Exchange Server instances. Microsoft Remote Connectivity Analyzer. Exchange Online or Microsoft Exchange Online is the cloud-based email solution that offers clients with the functionality of Exchange Server, but their data is hosted in Microsoft’s data centers which are managed by their certified professionals. This video explains what Microsoft Exchange Online is, and how it can help your organisation. For more information, please visit https://imprezait.co.uk/serv.

If you are planning an Exchange to Office 365 migration, then it can be quite confusing to understand the steps you need to take and in which order.

In this article, we’ll walk through the steps and decisions you need to take when migrating to Exchange Online. In part one we’ll consider the two most important first steps – deciding upon a migration approach and performing the core steps for identity. In part two, we’ll perform the Exchange Hybrid configuration and perform the migration of Mailboxes.

And, although we’re going to cover a lot of information in a short amount of time, you’ll find detailed guidance linked throughout.

Preparing your Exchange to Office 365 Migration

Before you begin a migration, it’s important to make sure that the source environment you are migrating from is in a good state.

If the Exchange environment you are running today isn’t healthy, then often that can serve as the motivator to move. After all, what can be an easier solution to bad day-to-day Exchange performance than moving to Office 365?

Unfortunately if you are experiencing day-to-day issues with Exchange, such as user issues accessing Exchange remotely, error messages and slow access times to mailboxes – or worse, database corruption – then moving to Office 365 will most likely be another source of trouble; not just for people accessing the environment you are trying to migrate from, but also when migrating as it’s likely you’ll experience failures along the way.

Your first step before beginning a migration should be to ensure that the environment is reasonably error free and correct any underlying issues prior to migration.

Read More: Patching your Exchange Environment

Hybrid migration or tool-based migration?

If you are thinking about moving your Exchange environment to Office 365 then you’re probably aware there are many options available.

From Microsoft, you have options for a Staged Migration and a Cutover Migration as well as a Hybrid Migration, and from third-party vendors a large number of different tools on the market for email archive migrations.

In general, if you have a version of Exchange Server that’s supported by Microsoft (Exchange Server 2010 and above) and it is part of your Active Directory then your default option should be an Exchange Hybrid Migration.

An Exchange Hybrid is based on either minimal or full Exchange Hybrid and creates a relationship between your on-premises Exchange servers and Exchange Online. This allows native mailbox moves, similar to between on-premises Exchange servers, with Outlook clients natively switching over without even needing to re-download offline copies of email. With full Hybrid, this also extends to secure mail flow between the two environments and co-existence functionality like free/busy and calendar sharing.

Azure AD

Azure AD Connect complements Exchange Hybrid, and you should expect to use Hybrid if you plan to synchronize your identity to the cloud. Azure AD Connect synchronizes your local Active Directory domain to Office 365, creating a copy of local AD accounts in Azure Active Directory that link back to the master copies. Azure AD Connect is also the part of the puzzle that maintains a consistent Global Address List between on-premises and the cloud.

Because AD and Azure AD Connect understand when there’s an existing Exchange organization in place, existing mailboxes on-premises won’t have mailboxes created in Office 365. You’ll be expected to use Exchange Hybrid to move mailboxes.

With a tool-based migration, the same rules do not apply. A fully Microsoft-supported Exchange Hybrid migration provides an excellent experience. However, especially in multi-forest environments it can be complex to set up correctly, hosted environments often do not allow for Azure AD Connect or Exchange Hybrid to be configured; and if you have legacy versions of Exchange it can involve installing additional servers running Exchange 2010 or higher which include the Hybrid components. Therefore, there are valid uses for a bespoke tool to migrate email to Office 365 – but in this article, we’ll assume you’ve made the decision to use Exchange Hybrid.

Read More: Methods for migrating to Office 365

Understanding pre-requisites and dependencies

Once you’ve decided that migrating to Office 365 using Exchange Hybrid is suitable for your organization, and you have a healthy environment to migrate, then you need to ensure you’ve completed necessary planning activities.

Many organizations who begin this journey will at this point ensure they have a design in place to support the changes that will take place. However, as you aren’t designing Office 365 or Exchange Online and instead designing the bridge to Office 365 then the design is often not as detailed as a full Exchange migration.

Instead, you are focusing on the changes necessary to your existing environment to make sure it is ready for the changes. In this article, we won’t cover this, but it’s worth remembering that most organizations, large and small, don’t just head into the unknown without making plans first.

The key pre-requisite for migrating to Exchange is ensuring the correct identity model is in place, first. There is a variety of options available when choosing an identity, but the most common scenario will be to utilize Azure AD Connect with synchronized identities and password hash sync.

Prior to this, we’ll perform a number of key tasks.

First, we’ll ensure that we’ve added all of our custom domains to our Office 365 tenant. These will need to match the email domains we use on-premises:

Ms Exchange Online Login

<Portal Domain

To add a new domain, choose <Path> and Add Domain. You’ll need to follow the steps, and verify each domain using a TXT record, similar to the one shown below:

Use your DNS provider’s control panel to add the corresponding TXT record to each domain, then continue the verification process.

Once you reach the point to add additional DNS records, it’s important you choose to Skip adding records such as Autodiscover or MX record changes.

This is crucial because at this point in the process your email is still looked after by on-premises systems, and you do not want to redirect clients to Office 365. The Hybrid relationship we create will manage this for us, later on.

We’ll sign-in to Office 365 using a login ID in the same format as an email address. In an Exchange Hybrid relationship, we expect this to match the Active Directory UserPrincipalName for each user. However, in many organizations, the login IDs are not in a format that will be suitable

In the above example, the issue is with the UserPrincipalName (UPN) suffix – the contoso.local part that typically matches the full AD Forest Name. To resolve this, we’ll add a UPN suffix to match our email domains registered with Office 365 in Active Directory Domains and Trusts:

We’ll then update the UserPrincipalName value for each user using Active Directory users and computers (or, ideally, PowerShell) to match the email address:

In most cases, this will not cause any user issues with sign-in, as nearly all organizations still expect users to login with the Pre-Windows 2000 / CONTOSOusername format. However, you should always validate this before making changes. After making these changes, the formats for login IDs will be similar to below:

Exchange Online Plan 1 Vs 2

We’ll also run the Microsoft IDFix tool against the domain. This step will highlight other issues within your Active Directory relevant to the domain sync. IDFix identifies errors, such as invalid email addresses (known as Proxy Addresses), invalid characters in usernames and other data and common issues, like using an invalid UPN suffix.

Use the list of issues identified by ID to make the corrections recommended, then install Azure AD Connect. In the example below, we’ve chosen Use Express Settings:

We’ll then follow the wizard steps to connect both as a global administrator to our Azure AD/Office 365 tenant, and to our local Active Directory. You’ll remember above though we added an additional UPN suffix to our local AD due to it not being a valid domain to use with Office 365. This will be highlighted during the installation wizard, however, because we’ve dealt with this it will be safe to continue:

Because we chose the Express Settings the wizard has pre-selected that we’ll use Password hash synchronisation. Our final choice is to ensure that an Exchange Hybrid Deployment is selected before beginning the install. This will ensure Azure AD Connect writes-back Exchange-related attributes to our local AD:

Once initial synchronization completes, you should be able to access the Microsoft 365 Admin Center and navigate to Users>Active Users and see synchronized accounts. You’ll see your AD users with a Sync Type of Synced with Active Directory:

Ms Exchange Online Plan 1

Further Reading:

Other areas you’ll need to consider

In addition, before you migrate mailboxes to Office 365, you need to consider other pre-requisites. Key areas you need to consider include:

Legacy Archiving

If you currently use a solution like Veritas Enterprise Vault for archiving or journaling email then this configuration will not work as-is with Office 365. Instead, the most common approach is to move archives to Exchange Online after migrating mailboxes.

In this scenario, stubs (or shortcuts, to use the EV term) will be re-hydrated with the original archive messages; or moved to archive mailboxes in Exchange Online. Quadrotech’s Archive Shuttle can handle this task and works well with an Exchange Hybrid migration.

Outlook clients

You’ll need to run a supported version of Outlook when connecting to Office 365. The following versions of Outlook are supported:

• Office 365 ProPlus
• Outlook 2019
• Outlook 2016
• Outlook 2013

Ideally, use the newest version (Office 365 ProPlus) that you have available. Outlook 2013, 2016 and 2019 will work with Office 365. If you are running Outlook 2010 today, then this can work with Exchange Online but for security reasons you will most likely want to block the protocols it uses.

Mobile devices

If you use Microsoft ActiveSync today to connect to Exchange on-premises, then you can allow mobile devices to continue to use this protocol when connecting to Exchange Online. Expect though in all but the most unusual circumstances to need to reconfigure ActiveSync devices to work with Exchange Online.

Instead, consider deploying the new Outlook mobile client to devices. If you choose to move to Microsoft Intune, then you can also use Intune to deploy and configure the new Outlook client. This supports additionally functionality to ActiveSync including the ability to schedule Teams meetings directly from the client, and new functionality like Focused Inbox. From a security perspective it can ensure that you have control over data, such as attachment downloads.

Internet Publishing

Ms Exchange Log In

The way you publish Exchange Server to the internet is important for a Hybrid deployment. This used to be crucial for all implementations, however, the new Hybrid Agent means that we can avoid many of the more complex areas for Exchange firewall and SSL certificate configuration for simple deployments.

There are a number of areas you must consider though:

• Autodiscover – In a Hybrid environment the Autodiscover service on-premises will be used by both on-premises mailboxes and Exchange Online mailboxes in Office 365. If you are moving to a model where users can access their mailboxes anywhere, then you will need to publish Autodiscover externally.
• Mail Flow – The Hybrid Agent removes the need to publish Exchange over HTTPS for mailbox moves and free/busy access. However, we’ll still need to allow mail flow between on-premises and Exchange Online. This requires TCP/25 connectivity both to and from Exchange Online Protection.
• Outbound access from Exchange servers to Exchange Online. Although the Hybrid Agent will allow access from Exchange Online to on-premises servers, your servers will still need to connect outbound for both the Hybrid Agent itself, and for requests such as free/busy.
• Client Access to Office 365. You’ll also need to ensure that all Office 365 clients like Outlook can access the service. Ideally this will be direct connection (instead of via a proxy server) accessing Office 365 by the fewest number of hops to the closest Microsoft Point of Presence. Use the Office 365 Network Onboarding Tool as a standing point.

In our example Exchange Organization, we’ve got a valid, third-party SSL certificate configured for Exchange Server for both our SMTP namespace (smtp.exchangelabs.co.uk) and HTTPS (autodiscover.exchangelabs.co.uk and outlook.exchangelabs.co.uk). We’ve allowed direct connectivity outbound on HTTPS to the required Office 365 and Exchange Online IP address ranges and SMTP connectivity to and from Exchange Online Protection.

Ms Exchange Online Plan 1 Price

Summary

In part one, we’ve selected the migration method to use for migration to Exchange Online, focusing on a Hybrid migration. We’ve then performed the core pre-requisite step for Exchange Hybrid – synchronizing Active Directory using Azure AD Connect. Finally, we’ve examined other areas, such as archiving, clients and connectivity.

Ms Exchange Online

In part two, we’ll implement Exchange Hybrid and perform mailbox moves.

Alternatively, you can download the full step-by-step guide here.