Skip to content

Office 365 Cutover mail migration – Exchange on-Premises pre requirements

The most common cause for a scenario, in which we fail to start the process of Office 365 cutover mail migration is – the lack of the Exchange on-Premises pre requirements.
The primary goals of the current article are:

  1. Provide the checklist of Exchange on-Premises pre-requirements
  2. Explain in details the reasons for each Exchange on-Premises pre requirements
  3. Provide you tools, which will help you to verify the existence of Exchange on-Premises pre requirements

Office 365 mail migration The gate of the herd.

The common denominator of most of the Office 365 mail migration project is what I described as the “racing herd”.

The mail migration project is executed in a hurry; we yearn to “push the mail migration button,” without any preparation and without any prior knowledge about “boring subjects” such as – cutover mail migration pre requirements, mandatory requirements, best practice and so on.

In case that luck is on our side, the cutover mail migration process is running successfully, but many times, the “luck lady” does not come, and the cutover mail migration process does not start!

The cutover mail migration pre requirements are the “little thing” that makes a difference between smooth and efficient mail migration project to the cloud vs. a scenario in which we are not able to meet the mail migration to Office 365 deadlines, and the memory of the migration to Office 365, leaves a bitter taste in the mouth.

Why does its so important to verify all the pre requirements before starting the cutover migration process

The scope of the current article

Office 365 cutover mail migration phases

The project of mail migration to Office 365 using cutover migration, includes three major phases:

  1. Pre-migration tasks
  2. The migration process
  3. Post-migration tasks

In the current article, we focus only on the first phase in which we prepare our environment and our mail infrastructure to the Office 365 cutover mail migration process.

What are the cutover migration phases

Office 365 cutover mail migration pre requirement’s classification

The “first phase” of Office 365 cutover mail migration can include a couple of parts such as – learning about the specific characters of cutover mail migration, building a lab for testing the designed migration process, and verifying that all the pre requirements are fulfilled.

The phase of the “cutover mail migration pre requirements” can also be divided into different sections such as:

  • User desktop pre requirements
  • Network infrastructure pre requirements
  • Office 365 infrastructure pre requirements
  • Exchange on-Premises pre requirements

In the current article, we will relate only to the subject of Exchange on-Premises pre requirements

Office 365 cutover mail migration pre requirements classification

Office 365 different types of mail migration

Office 365 provides three built-in types of mail migration option from Exchange on-Premises server:

  1. Cutover mail migration
  2. Stage mail migration
  3. Exchange Hybrid mail migration

The current article is dedicated to the Office 365 cutover mail migration and the Exchange on-Premises server pre requirements.
The important thing then we should know is that the ” Exchange
on-Premises server pre requirements” that are relevant to the Office 365 cutover mail migration are relevant and almost identical to the rest of the Office 365 mail migrations.

The factor of Exchange on-Premises public availability

All the different types of Office 365 mail migration options, dictate the mandatory need in which Exchange on-Premises server will need to have a “public presence” which is translated to:

  1. Public IP address.
  2. Public name.
  3. Public certificate.
The relevance if the pre requirements to the different Office 365 mail migrations -Common denominator

The mail migration protocol

Regarding the subject of the “mail migration protocol” the Office 365 mail migration methods are classified in the following way:

Office 365 cutover mail migration and Office 365 stage mail migration, are implemented by using the Outlook Anywhere protocol. The Exchange Online server will “fetch” the Exchange on-Premises mailboxes, by using the RPC over HTTPS (Outlook Anywhere) protocol.

Office 365 Exchange Hybrid mail migration, is implemented via the Exchange on-Premises EWS (Exchange web services) interface. In other words, the Exchange hybrid environment doesn’t need to use the RPC over HTTPS (Outlook Anywhere) protocol for mail migration.

The relevance if the pre requirements to the different Office 365 mail migrations - Mail migration protocol -02

What is the exact meaning of “mail migration”?

Before we continue with the description of the Office 365 cutover mail migration, it’s important that we will agree on the definition of the term “mail migration”.

The first association that appears in our mind regarding the term “mail migration” is – a migration of Exchange mailboxes.

This association is partially true because Exchange mailbox doesn’t have any life of its own.

The meaning is that Exchange mailbox must be “attached” or “connected” to a user account.

Office 365 cutover migration - What is the exact meaning of mail migration -01

The process of Office 365 cutover mail migration is designed to implement a migration process which will create two separated “migration channels”.

1. User \ group account migration process

One migration channel is – the user and group account that will be copied from On-Premise Active Directory to the Windows Azure Active Directory.

2. Exchange on-Premises mailbox migration process

The second migration channel is the Exchange mailbox process, in which all the
Exchange on-Premises mailboxes (100%) will be copied to the Exchange Online infrastructure.

Office 365 cutover migration - What is the exact meaning of mail migration -02

Office 365 cutover mail migration – User and mailbox migration

Additional detail that I would like to emphasize is that the term “migration,” is translated into a copy operation and not move operation.

When we say Office 365 cutover mail migration, the term “cutover” could be misleading because, in reality, we don’t “cut off” the Exchange on-Premises mailboxes (move) but instead, copy the Exchange on-Premises mailbox content to the Exchange Online mail server.

Throughout the process of Office 365 cutover mail migration, there will be two user mailboxes at the same time.

The “original Exchange mailbox” stored in the Exchange on-Premises, and the copy of the user mailboxes that is stored in the Exchange Online.

Office 365 cutover migration - Exchange mailbox migration is Copy mailbox -03

What are the mandatory pre requirements of the Exchange on-Premises server?

Later on, we will review in details each of the “pre requirements” that Exchange on-Premises server need to support for implementing the Office 365 cutover mail migration.

In a nutshell, the most essential and mandatory Exchange on-Premises pre requirements are:

  1. Public availability
  2. Support the options Outlook Anywhere.
Office 365 cutover migration - The two mandatory requirements form Exchange on-Premises -04

To be able to simplify the cutover mail migration process, we can use a metaphor in which Exchange Online server reaches out his hand, knocking your organization network and asking to get a copy of all the On-Premise Active Directory users, groups and contact, and all the user mailboxes stored in the Exchange on-Premises server\s.

The organization representative who communicates with “Office 365” is the
Exchange on-Premises server.

To be able to enable this communication channel between Office 365 and you’re Exchange on-Premises server, the Exchange on-Premises will need to have public availability.

The term “public availability” is translated into three different components:

  1. Public IP – a Public IP address that is accessible to external hosts. The
    Exchange on-Premises public IP address will be “mapped” to the Exchange on-Premises public name.
  2. Public name – the more accurate term is the FQDN (fully qualified domain name). Exchange on-Premises server will need to use a public name which external hosts such as Exchange Online use for addressing our Exchange on-Premises server. For example – o365info.com
  3. Public certificate – technically speaking, the server certificate is not directly related to the communication process with the Exchange on-Premise server because all we really need is just a public IP address. The reason that we “wrap” the public certificate with the term “public availability” is because the need for a public valid server certificate is a mandatory requirement of the Office 365 cutover mail migration.
Office 365 cutover migration - Exchange on-Premises server Pre requirements - Public availability -05

Cutover mail migration | Phase A

The Office 365 cutover mail migration initialized from the “Office 365 side” (Exchange Online admin portal) that need to locate and communicate Exchange on-Premise server.

The communication channel between Exchange Online and Exchange on-Premises must be implemented as a secure communication channel (encrypted using SSL).

The establishment of the communication channel will serve for the purpose of – copy information from the On-Premise Active Directory and Exchange on-Premise server.

Office 365 cutover migration - The logic of the mail migration process and Exchange on-Premises pre requirements -01

1. Locating our Exchange on-Premises server

As mentioned, the Office 365 cutover mail migration process, is initialized from the Office 365 side that “reaches out his hand,” and accesses the Exchange on-Premises server.

To enable Office 365 cutover mail migration to locate our Exchange on-Premises server, we need to provide the Office 365 cutover mail migration the required information.

The preferred \ recommended method is – by using the Autodiscover process.
Given that our Exchange on-Premises server have the required setting for Autodiscover, when we create the cutover mail migration batch, Office 365 will use the “domain name” of the E-mail message that we will provide for locating “our” Exchange on-Premises server.

In case that our Exchange on-Premises server doesn’t support Autodiscover or the Autodiscover settings is incorrect, we can provide Office 365 the required information about the Exchange on-Premises server manually.

2. Communicating with the Exchange on-Premises server.

After the Office 365 cutover mail migration locates our Exchange on-Premises server, he needs to “talk” with Exchange on-Premises server for the purpose of asking a copy of existing On-Premise Active Directory users and Exchange on-Premises mailboxes.

The mandatory requirement for the communication channel from Office 365 side is that the communication will be implemented by using the HTTPS protocol (port 443).

The Exchange on-Premises server will need to identify himself by providing a valid public certificate.

Office 365 cutover migration - The logic of the mail migration process and Exchange on-Premises pre requirements -02

Cutover mail migration | Phase B

The communication channel between Office 365 and the On-Premises environment (Exchange on-Premises) is implemented by using the SSL protocol.

The actual migration process is implemented by using the RPC protocol. The RPC protocol is positioned “above” the SSL protocol.

This implementation, described as encapsulation (the method of using a protocol that used additional protocol) and in Exchange based environment, this method described as RPC over HTTPS.

The friendly name for this method is – Outlook Anywhere.

Office 365 cutover migration - The logic of the mail migration process and Exchange on-Premises pre requirements -03

1. Exchange on-Premises and Outlook Anywhere

To be able to implement the cutover mail migration, Exchange on-Premises will need to support Outlook Anywhere.

Note: The option of Outlook Anywhere relies on the “public availability” of the Exchange on-Premises and also the need for a server certificate.

Outlook Anywhere doesn’t dictate the need for a public certificate, but the Office 365 cutover mail migration does.

2. Exchange Online | The required user credentials

The Office 365 cutover mail migration is based on the assumption that we will be able to copy all the On-Premise Active Directory content (not all the content but most of it) and all the Exchange on-Premises mailboxes.

When we define the Office 365 cutover mail migration setting (migration endpoint), we will need to provide a username + user credentials which will be used by Office 365 cutover mail migration when he connects our Exchange on-Premises server.

The technical term for the “user” that we will provide to the Office 365 cutover mail migration is – migration administrator.

For a cutover migration, the migration administrator account must be:

A member of the Domain Admins group in Active Directory in the on-premises organization.

Or

Assigned the FullAccess permission for each on-premises mailbox.

Or

Assigned the Receive As permission on the on-premises mailbox database that stores the user mailboxes.

Office 365 cutover migration - The logic of the mail migration process and Exchange on-Premises pre requirements -04

Exchange on-Premises certificate

A mandatory need of the Office 365 cutover mail migration is – the need that the Exchange on-Premises server will use a public valid certificate.

In many scenarios, this mandatory need is annoying the person who is responsible for the Office 365 cutover mail migration process because not all the organizations use a valid public certificate. Another possible scenario is a scenario in which the organization uses
Exchange on-Premises certificate, but uses a public certificate (certificate that was not enrolled by a public certificate authority).

Q1: Is there a way to implement the Office 365 cutover mail migration without using an Exchange on-Premises public valid certificate?

A1: No, this is a mandatory requirement

Q2: What is the meaning of “public valid certificate”?

A2:

  • The meaning of “public certificate” is – a certificate that was purchased from a well-known public CA (certificate authority).
  • The meaning of “valid certificate” is – a certificate that has a valid expiration date + a valid host name \s or a valid domain name.
Office 365 cutover migration - Exchange on-Premises server Pre requirements - Server certificate -01

Q4: Why does the cutover mail migration “insist” using a public certificate?

A4: The Office 365 cutover mail migration needs to verify that Exchange on-Premises server have a public certificate for two main reasons:

1. Data privacy and data integrity

The Office 365 cutover mail migration is implemented over a public network infrastructure that considers as a non-private or non-safe environment. To be able to fulfill the most basic security need for data privacy and data integrity, the Office 365 cutover mail migration is implemented by using the SSL protocol. The implementation of SSL protocol requires a server certificate.

Note: Technically speaking SSL doesn’t place a mandatory requirement for a public certificate, and even a private certificate is “OK”.

2. The need for authentication and identification

Although we use the term “our Exchange on-Premises server”, Office 365 doesn’t really know or trust our Exchange on-Premise server.

When using SSL, the mechanism that we use for fulfilling the need of – verifying the identity of a particular entity is, by using a public certificate that was enrolled by a public CA.

When the Office 365 cutover mail migration connects Exchange on-Premises server, Office 365 will need to be sure beyond all doubts, that the Exchange on-Premises server which represents a particular domain is really who he claims to be.

The ability to proof the Exchange on-Premises server’s identity is implemented when Exchange on-Premises displays a valid public certificate that was provided by a CA, which Office 365 trusts.

Office 365 cutover migration - Why does Exchange on-Premises need to have public certificate -02

Q5: What type of a public certificate can be used by Exchange on-Premises server?

A5: A valid server certificate could be

SAN (subject alternative name) certificate or a wildcard certificate.

Case 1 – using an SAN certificate

The SAN certificate includes information about hosts, who are authorized to use the certificate. The information about this host appears as FQDN (fully qualified domain name).

In Exchange based environment, that SAN certificate will need to include at least two hosts (FQDN) names:

  1. The Exchange on-Premises server public name.
  2. The Autodiscover hostname who represents a specific domain name.

For example: in our specific scenario, the organization domain name is o365info.com

  • The Exchange on-Premises server public name is – mail.o365info.com
  • The Autodiscover hostname is – autodiscover.o365info.com

Case 2 – using a wildcard certificate

In case that we use a wildcard certificate, the certificate “covers” all the hosts in a specific domain name.

For example – a wildcard certificate for the domain name will include the following information – *.o365info.com

All the host names who appear “under” this domain name such as “mail” (the hostname of our Exchange on-Premise server) or Autodiscover, considers as a valid host name that is authorized to use the certificate.

Office 365 cutover migration - Exchange on-server Pre requirements - Server certificate - certificate type -03

Verifying my Exchange on-Premises server certificate

As mentioned, the Office 365 cutover mail migration mandatory requirement is that the Exchange on-Premises server will use a public valid certificate.

In the following section, I would like to review briefly a “standard” SAN public certificate and display the certificate parts which we need to check.

Certificate date validation

The most basic parameter that needs to be verified with a server certificate is the subject of the certificate validation date.

When we select the general tab, we can see the section named – valid from, that the specific certificate is valid until 2/2/2018

How to verify my Exchange server certificate -01

Certificate and the host named

In our specific scenario, the organization domain name is – o365info.com

The Exchange on-Premises server public hostname is – mail.o365info.com
the Autodiscover record for the o365info.com domain is – autodiscover.o365info.com
When we select the details tab, we can see the section named – Subject Alternative Name, the host names who include in the SAN certificate.

In our scenario, we look for

  • A valid Autodiscover hostname
How to verify my Exchange server certificate -02
  • A valid Exchange on-Premises public name – hostname
How to verify my Exchange server certificate -03

Certificate and public CA (certificate authority).

As mentioned, when using Office 365 cutover mail migration, the Exchange on-Premises server certificate must be a “public certificate” that was provided by a public CA.

When we select the Certificate Path tab, we can see the section named – Certificate Path we can see information about the public CA that provides the certificate. In our specific scenario, the public CA is
Go Daddy.

How to verify my Exchange server certificate -04

Q6: In the case that my Exchange on-Premises server doesn’t include the server certificate, can you instruct how to purchase and install the required server certificate?

A6: The subject of “how to install a server certificate on Exchange on-Premises server” is out of the scope of our current article.

The communication channel between Exchange Online and Exchange on-Premises server

An additional “part” that I would like to add to our Office 365 cutover mail migration checklist is – the mandatory need for enabling external hosts such as Office 365 and Exchange Online to access the Exchange on-Premises server via port 443 (SSL).

In reality, the Exchange on-Premises server is nor relay “exposed” to the external network and communicate directly with external hosts such as – Exchange Online.

The access to Exchange on-Premises server implemented via the mediation of Firewall or Proxy servers, which represent our internal hosts.

Any communication request from external hosts will reach the Firewall and will be “forwarded” to the “internal Exchange on-Premises server.”

Bottom line – to be able to start the Office 365 cutover mail migration, Exchange Online will need to access Exchange on-Premises server using port 443.

Office 365 cutover migration - Exchange on-Premises -Pre requirements - incoming communication port -02

Exchange on-Premises server version

Q7: What is the Exchange on-Premises server version that supports Office 365 cutover mail migration?

A7: All of the existing Exchange on-Premises server versions starting with
Exchange on-Premises 2003.
Technically speaking, Exchange 2003 on-Premises is not supported anymore, but it doesn’t mean that you cannot try to use Office 365 cutover mail migration and most of the chance are that if the Exchange 2003 includes all the pre requirements, the Office 365 cutover mail migration will complete successfully.

Office 365 cutover migration - Exchange on-Premises server Pre requirements - Exchange server version -03

Q8: Does the Exchange on-Premises server need to include a specific service pack, a particular Rollup or a specific cumulative update?

A8: The interesting thing regarding the subject of Exchange on-Premises server minimum System requirements for implementing Office 365 cutover mail migration is – that, as far as I know, there is no formal article that defines this Exchange on-Premises software requirements.

My answer to this question is – the general rule that says – the more updated version is better.

For example, in case that your Exchange on-Premises server is an Exchange 2010 server, the recommended software version is Exchange service pack 3 + Exchange 2010 Rollup 32.

It doesn’t mean that a lower Rollup will not work, but in case that we want to maximize our chances for implementing a successful Office 365 cutover mail migration process, the more advanced Exchange 2010 Rollup Increases the likelihood for a successful mail migration process.

Exchange on-Premises server and the Outlook Anywhere protocol

As mentioned, the mandatory requirement for implementing the Office 365 cutover mail migration is that the Exchange on-Premises will support the Outlook Anywhere feature.

In case that your Exchange on-Premises don’t support the Outlook Anywhere option or in case that you are not familiar with the Outlook Anywhere option, here is a very brief review of the Outlook Anywhere configurations setting as they appear in Exchange 2010 and Exchange 2013.

Exchange 2010

In Exchange 2010, we activate the Outlook Anywhere feature by using the following path:

Server Configuration => Client access => Enable Outlook Anywhere

In the following screenshot, we can see that the Outlook Anywhere was already enabled.

Verifying Outlook anywhere on Exchange 2010 server -01

If we want to view the Outlook Anywhere setting, we can select the properties menu.

In the following screenshot, we can see an example of the Outlook Anywhere settings.

The hostname who appears in the “External host name” section, is the host name the Outlook will address.

Verifying Outlook anywhere on Exchange 2010 server -02

Exchange 2013

In Exchange 2013, we activate the Outlook Anywhere feature by using the following path:

servers => servers => <Server name>

In the following screenshot, we can see that the Outlook Anywhere was already enabled.

Verifying Outlook anywhere on Exchange 2013

In the following table, you can find links to articles that include guideline regarding the steps that need to be implemented for “activating” the Outlook Anywhere feature in different Exchange server versions:

Exchange server Outlook Anywhere
Exchange 2003
How to Configure Outlook Anywhere with Exchange 2003
Exchange 2007
How to Enable Outlook Anywhere Exchange 2007
Exchange 2010
Enable Outlook Anywhere Exchange Server 2010
Exchange 2013
Outlook Anywhere
Exchange 2016
Configure Outlook Anywhere

Verifying the Outlook Anywhere service by using Remote Connectivity Analyzer.

Before we start the Office 365 cutover mail migration process, the best practice is to test and verify that our Exchange on-Premises support Outlook Anywhere option and that we can successfully implement a successful Outlook Anywhere session with our Exchange on-Premises.

The good news is that we have a very handy web-based tools for this purpose
named – Remote Connectivity Analyzer.

The Remote Connectivity Analyzer is a Microsoft web-based tool useful and powerful tool that is used for testing many different Exchange on-Premises and Exchange Online services.

The most powerful feature of the – Remote Connectivity Analyzer tool is the ability to provide a detailed report about “what happens behind the scenes” of a specific communications protocols.

In case that the communication process fails, we can use the report information for finding the possible cause of the communication failure

In our scenario, before we start the Office 365 cutover mail migration, we want to verify that:

  1. The outlook Anywhere feature is enabled on our Exchange on-Premises server.
  2. That external client can connect Exchange on-Premises using the Outlook Anywhere (RPC \ HTTPS) protocol.

In the following section, we demonstrate the steps that need to be implemented for using the Remote Connectivity Analyzer tool for verifying Outlook Anywhere connectivity.

To access the Remote Connectivity Analyzer tool, we will use the following URL address: https://testconnectivity.microsoft.com

  • We will select the Exchange tab
  • Under the section named- Microsoft Office Outlook Connectivity Tests, we will select the option – Outlook connectivity.
Using Exchange remote connectivity analyzer to verify Outlook AnyWhere connectivity -01

In the next screen, we will need to provide the user credentials that represent the Exchange on-Premises recipient who needs to access his mailbox.

  • In the E-mail address section, we will provide the E-mail address of the recipient – david@o365info.com (number 1).
  • In the domain\user name (or UPN) section, we will type the user credentials in a UNC-based format –o365info\david (number 2).
  • We will provide the user password (number 3).

By default, the Outlook connectivity test will try to use the option of Autodiscover (use Autodiscover to detect server settings).

Using Exchange remote connectivity analyzer to verify Outlook AnyWhere connectivity -02
  • We will need to check the box in which we approve that the Remote Connectivity Analyzer tool is authorized to use our credentials (number 1).
  • We will need to write down the captcha sequins and select Verify
Using Exchange remote connectivity analyzer to verify Outlook AnyWhere connectivity -03

To initialize the Microsoft Office Outlook Connectivity Tests, we will select Perform Test

Using Exchange remote connectivity analyzer to verify Outlook AnyWhere connectivity -04

In the following screenshot, we can see that the Microsoft Office Outlook Connectivity Tests is running (the Remote Connectivity Analyzer tool is trying to access our Exchange on-Premises server and connect to David’s mailbox using Outlook Anywhere protocol).

Using Exchange remote connectivity analyzer to verify Outlook AnyWhere connectivity -05

In the following screenshot, we can see that the Microsoft Office Outlook Connectivity Tests successfully complete.
The meaning is that the Exchange on-Premises support Outlook Anywhere services and that we were able to access the recipient mailbox.

Notice the small white arrow that appears on the left of the result.
The information that is displayed by default is just the summary of the test result. In case that we want to get a details information about each of the steps that were included in the simulation, we can click on the small white arrow and the information will expand.

Using Exchange remote connectivity analyzer to verify Outlook AnyWhere connectivity -06

In the following screenshot, we can see we have clicked on the small arrow.

The test result was expanded, and now we can see that the Microsoft Office Outlook Connectivity Tests consist of two different parts:

The Autodiscover test which was used for locating and connecting the Exchange on-Premises server and the second part which is the Outlook Anywhere communication channel.

Using Exchange remote connectivity analyzer to verify Outlook AnyWhere connectivity -07
o365info Team

o365info Team

This article was written by our team of experienced IT architects, consultants, and engineers.

This Post Has 3 Comments

  1. Hello,

    Just have a question can you please explain about the batches like how many batches we can create during the cutover migration . The below MS article is but confusing they mentioned that A maximum of 2,000 mailboxes can be migrated to Office 365 by using a cutover Exchange migration. However, it is recommended that you only migrate 150 mailboxes. So Can we create multiple batches, or do we need to create one batch only with 2000 users if we have that much of users ? If yes that what about the recommendation about 150 users/ mailboxes ?

    https://support.office.com/en-us/article/What-you-need-to-know-about-a-cutover-email-migration-to-Office-365-961978ef-f434-472d-a811-1801733869da

    1. Hello Amit,

      Exchange cutover migration doesn’t support the option of “batches”.

      The main character of Exchange cutover migration is that this type of migration was created to migrate 100% of the Active Directory users + 100% Exchange on-Premises mailboxes at one time.

      In case you need to implement the mailbox migration in batches, meaning to migrate only a specific group of Exchange on-Premises mailboxes, you will need to use one of the following Exchange migration options:

      1. Exchange stage migration
      2. Exchange Hybrid

Leave a Reply

Your email address will not be published. Required fields are marked *