New Post has been published on o365info.com
New Post has been published on http://o365info.com/office-365-cutover-mail-migration-exchange-on-premises-pre-requirements/
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 main goals of the current article are:
Provide the checklist of Exchange on-Premises pre-requirements
Explain in details the reasons for each Exchange on-Premises pre requirements
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 versus, 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.
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:
Pre-migration tasks
The migration process
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.
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 different types of mail migration
Office 365 provides three built-in types of mail migration option from Exchange on-Premises server:
Cutover mail migration
Stage mail migration
Exchange Hybrid mail migration
The current article is dedicated to the Office 365 cutover mail migration and the Exchange on-Premises server pre requirements, but 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:
Public IP address.
Public name.
Public certificate.
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.
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.
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 mail migration – User and mailbox migration
An 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.
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 basic and mandatory Exchange on-Premises pre requirements are:
Public availability
Support the options Outlook Anywhere.
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:
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.
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
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.
Cutover mail migration | Phase A
The Office 365 cutover mail migration is 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.
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 are 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.
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.
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 in addition 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.
Additional reading
Assign permissions to migrate mailboxes to Exchange Online
Recipients Permissions
Migrate all mailboxes to Exchange Online with a cutover migration
Perform a cutover migration of email to Office 365
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 public valid 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.
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 specific 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 who represents a specific 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.
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:
The Exchange on-Premises server public name.
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.
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 briefly review 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
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
A valid Exchange on-Premises public name – hostname
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.
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.
Instead, I will provide some useful links, that include instructions for the task of installing the server certificate for Exchange on-Premises server based on the specific Exchange on-Premises server version.
Exchange server certificate Exchange 2003 Configuring Exchange 2003 for Client Access
How to Install a Public 3rd Party SSL Certificate on IIS on SBS 2003
Exchange 2007 Add an SSL certificate to Exchange 2007
Certificate Manager for Exchange 2007
Exchange 2010 Add an SSL certificate to Exchange 2010 Exchange 2013 Add an SSL certificate to Exchange 2013 Exchange 2016 Configure Exchange 2016 certificates
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 will be 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.
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.
Q8: Does the Exchange on-Premises server need to include a specific service pack, a specific Rollup or a specific cumulative update?
A8: The interesting thing regarding the subject of Exchange on-Premises server required or 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 requirement.
My answer to this question is – to use 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 12.
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.
In the following table, you can find links to the Exchange on-Premises most updated service pack, Rollup and Cumulative Updates based on the specific Exchange on-Premises version.
Exchange service pack and software updates Exchange 2003 Exchange 2003 service pack
Exchange Server 2003 Service Pack 2
Exchange 2007 Exchange service pack
Exchange Server 2007 Service Pack 3
Exchange 2007 Rollup 18
Update Rollup 18 for Exchange Server 2007 Service Pack 3 (KB3078672)
Exchange 2010 Exchange service pack
Microsoft Exchange Server 2010 Service Pack 3 (SP3)
Exchange 2010 Rollup 12
Update Rollup 12 For Exchange 2010 SP3 (KB3096066)
Exchange 2013 Exchange 2013 service pack
Microsoft Exchange Server 2013 Service Pack 1 (SP1)
Exchange Cumulative Update 12
Cumulative Update 12 for Exchange Server 2013
Exchange 2016 Exchange 2016 Cumulative Update 1
Cumulative Update 1 for Exchange Server 2016
If you need additional information about the Exchange server version, you can use the following links
Exchange Server and Update Rollup Build Numbers
Exchange Server 2013 and 2016 Build Numbers (with Cumulative Updates)
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.
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.
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.
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 for the communication failure
In our specific scenario, before we start the Office 365 cutover mail migration, we want to verify that:
The outlook Anywhere feature is enabled on our Exchange on-Premises server.
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.
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 – [email protected] (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).
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
To initialize the Microsoft Office Outlook Connectivity Tests, we will select Perform Test
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).
In the following screenshot, we can see that the Microsoft Office Outlook Connectivity Tests successfully complete. The meaning is that the Exchange on-Premises that we test support the 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 appears 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.
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.
Additional reading
What you need to know about a cutover email migration to Office 365
Perform a cutover migration of email to Office 365
Cutover Exchange migration
Migrate all mailboxes to Exchange Online with a cutover migration
Video links
Office 365 Cutover Migration Deep Dive
Migrating to Exchange Online: (03) Cutover Migration
Migrating to Exchange Online: (02) Planning to Migrate
Now it’s Your Turn! We really want to know what you think about the article
