Migration from onPremise to Office 365 – Step by Step – Part 2- Exchange onPrem to Exchange Online (Exchange Hybrid Classic Full)
In Part 2 we will see how to migrate from Exchange onPrem to Exchange Online. This Blog Post Series consists of 6 parts. So if you missed one check them out as follows.
This post is split into multiple parts
Part 1 … will cover the prerequisites like synchronize your onPrem users to Office 365 with Azure AD Connect.
Part 2 … will cover migration from Exchange onPrem to Exchange Online and here especially Exchange Hybrid classic full.
Part 3 … will cover moving user mailboxes from onPrem to Exchange Online.
Part 4 … will cover troubleshooting Exchange Hybrid
Part 5 … will cover migration from Skype for Business onPrem users to Skype for Business Online and Teams.
Part 6 … will cover Skype for Business Hybrid Connectivity and Teams Direct Routing
Part 7 … will cover troubleshooting Skype for Business Hybrid
Migration from Exchange onPrem to Exchange Online (Exchange Hybrid Classic Full)
Create a hybrid deployment with the Hybrid Configuration wizard
Exchange hybrid deployment features
For my Lab environment I use the Exchange Classic Full Hybrid mode. This mode is for permanent hybrid operation where the Sources of Authority (SOA) will still be your onPrem Active Directory and the users will be synchronized to Office 365 resp. Azure Active Directory.
Whereas minimal and express are only temporary modes and in the end when all mailboxes moved into Office 365, Azure AD Connect will be removed and you end up in a cloud only operation.
So if you don’t want or can give up your onPrem network, full hybrid is the way to go.
Full Hybrid is also in a modern mode available which makes sense for companies they not be able or want to provide and publish inbound HTTPS connections to their Exchange Mailbox Server from Exchange Online. Inbound SMTP traffic of course is still needed.
In modern mode therefore the Hybrid Agent act as a application proxy like the Azure Application Proxy and only outbound connections are required. So the agent establishes an outbound connection to Exchange Online and over this TCP Tunnel Exchange Online can access directly to the onPrem Exchange Mailbox Server.
Under https://docs.microsoft.com/en-us/exchange/hybrid-configuration-wizard-options you will see a detailed table with differences between the several modes.
So let’s start and click on configure …
You have to provide your Office 365 Tenant Admin credentials in order the Hybrid Configuration Wizard (HCW) is able to configure Exchange Online.
As you can see I were logged into the Exchange admin center (EAC) with my Office 395 Admin account.
Here the wizard tries to detect automatically the optimal Exchange Server for Hybrid Configuration. In Exchange 2010 or Exchange 2013 you have to specify a Client Access Server Role manually.
For the My Office 365 organization is hosted by list below, in most cases you should select Office 365 Worldwide.
At this point you need to provide your onPrem Exchange Admin credentials and your Office 365 Admin account credentials.
Now the Wizard tries to log in with the provided credentials using PowerShell into on-premise Exchange and Exchange Online.
On the next page we must configure the Hybrid Features. We want a Full Hybrid Configuration and also want to transfer some organization settings from our onPrem environment into Exchange Online, so I checked the Organization Configuration Transfer checkbox.
Items included in this transfer:
- Retention Policy
- Retention Policy Tags
- OWA Mailbox Policy
- Mobile Device Mailbox Policy
- Active Sync Mailbox Policy
Read more about Organization Configuration Transfer
In my Lab environment I use two domains, the braintesting.de is used for the AD Domain internal and braintesting.net is the default Mail and SIP Domain. So for Exchange Auto Discover I will use braintesting.net.
For the Hybrid Topology on the next page I will use Exchange Classic Hybrid Toplogy. With this mode you have a full Exchange Hybrid experience with no limitations contrary to the Exchange Modern Hybrid Topology which comes with some limitations.
Overview of the Modern Hybrid limitations
Both modes are for permanent Hybrid operation, so your Source of Authority (SOA) remains in your onPrem Active Directory and will be synchronized over Azure AD Connect to Office 365 and Azure AD.
Note: For Classic Hybrid Toplogy your environment should provide public access from the internet and therefore Client Access and SMTP Transport should be published with an public IP Address. Internet connections will be established from both sides, Exchange Online to Exchange onPrem and vice versa.
Modern Hybrid Topology only needs an outgoing internet connection, here will be installed an Hybrid Agent which is responsible for the communication between Exchange onPrem and Exchange Online. The Hybrid Agent is based on Azure AD Application Proxy technology and will establish a connection from inside your onPrem network into Office 365 and Exchange Online.
Note: All other modes besides from Full Classic and Full Modern, like minimal and express will lead to move completely to Office 365 and disabling Azure AD Connect and therefore the synchronization between both environments.
A great overview about Exchange Hybrid you will find under the link below, unfortunately only in german.
Provide Office 365 Exchange Online your onPrem Credentials of Exchange to create a migration endpoint in Exchange Online.
On the next page below Hybrid Configuration you configure the routing of the mail transport between Exchange onPrem and Exchange Online. You can select between two options. First choice will handle the transport between your Client Access/Mailbox server and Exchange Online directly and second my preferred option is to use an Edge Transport server placed in the perimeter network for securing the mail transport between onPrem and Exchange Online.
Read more about these two options under https://docs.microsoft.com/en-us/previous-versions/exchange-server/exchange-150/jj156682(v=exchg.150)?redirectedfrom=MSDN
- Client Access and Mailbox servers The typical transport configuration is for your on-premises Client Access and Mailbox servers to handle message delivery and connect with the Exchange Online Protection (EOP) service in the Office 365 tenant organization. In this configuration, a Receive connector is configured on your on-premises Client Access servers to accept secure inbound connections from the EOP service in your Office 365 tenant organization. Additionally, a Send connector is configured on your on-premises Mailbox servers to initiate outbound connections to the EOP service in your Office 365 tenant organization. Together, these two connectors help to enable secure bi-directional mail transport between the on-premises and Exchange Online organizations.
- Edge Transport servers If you have Edge Transport servers in your organization, you can choose to configure the Edge Transport servers to handle message delivery and connect with the EOP service in the Office 365 tenant organization. In this configuration, a Receive connector is configured on your on-premises Edge Transport servers to accept secure inbound connections from the EOP service in your Office 365 tenant organization. Additionally, a Send connector is configured on your on-premises Edge Transport servers to initiate outbound connections to the EOP service in your Office 365 tenant organization. Together, these two connectors help to enable secure bi-directional mail transport between the on-premises and Exchange Online organizations.
Edge Transport servers with hybrid deployments
Choose your Edge Transport servers to configure secure-bi-directional hybrid mail transport with Exchange Online.
In my Lab environment I only have one Edge Server. If you have more than one Edge Server, for example if you have two Active Directory sites and also two Exchange sites with one Edge per site, you can configure here both Edge Server for secure-bi-directional hybrid mail transport.
Optional when you click on Advanced, you can check Enable centralized mail transport (CMT). CMT is a hybrid mail flow scenario, where all outbound mails from Exchange Online are routed through on-premises servers first before sending it to the internet. Incoming mail flow is still controlled over your public MX records, but you have to keep an important point in mind, if you have checked CMT.
If you set your MX records to Office 365/Exchange Online for incoming mails, and also checked/enabled centralized mail transport (CMT), yes of course, incoming mails from external will be hit first directly in Exchange Online, but because of enabled CMT, Exchange Online will deliver the mail for users homed in Exchange Online not directly into their mailbox, it will first route the mail to your onPrem Exchange Servers, they determine that the users mailbox is homed in Exchange Online and will route the mail back to Exchange online over the outbound connector for Office 365.
So final conclusion, if CMT is enabled, all mails, outbound and inbound are first routed through your onPrem Exchange environment!
Note: If you have CMT enabled and configured multiple or a minimum of two Edge servers and from different AD sites, in this case, if one AD Site fail, your Exchange Online users still be able to send and receive mails (receive if the MX record point to your onPrem environment) over the second site and Edge server.
Transport routing in Exchange hybrid deployments
Inbound messages from the Internet
As part of planning and configuring your hybrid deployment, you need to decide whether you want all messages from Internet senders to be routed through Exchange Online or your on-premises organization. All messages from Internet senders will initially be delivered to the organization you select and then routed according to where the recipient’s mailbox is located. Whether you choose to have messages routed through Exchange Online or your on-premises organization depends on various factors, including whether you want to apply compliance policies to all messages sent to both organizations, how many mailboxes are in each organization, and so on.
The path messages sent to recipients in your on-premises and Exchange Online organizations take depends on how you decide to configure your MX record in your hybrid deployment.
The preferred method is to configure your MX record to point to Exchange Online Protection (EOP) in Microsoft 365 and Office 365 as this configuration provides the most accurate spam filtering.
Mail flow best practices for Exchange Online, Microsoft 365, and Office 365 (overview)
If you want Microsoft 365 or Office 365 to receive all email addressed to email@example.com, the MX record for contoso.com should point to Microsoft 365 or Office 365, and it will look like the following example:
TTL: 1 hour
So the mx records for both lab environments have to be
Btw. regarding dns records, your autodiscover dns record should still point to your on-premise environment with exchange classic full hybrid.
Office 365 Exchange Hybrid Deployments Busting The Autodiscover Myth
Before we move on, be clear that we are discussing Exchange hybrid and in this deployment model Autodiscover must point to the on-premises Exchange infrastructure.
The Hybrid Configuration wizard doesn’t configure the routing for inbound Internet messages for either the on-premises or Exchange Online organizations. You must manually configure your MX record if you want to change how your inbound Internet mail is delivered.
- If you change your MX record to point to the Exchange Online Protection service in Microsoft 365 or Office 365: This is the recommended configuration for hybrid deployments. All messages sent to any recipient in either organization will be routed through the Exchange Online organization first. A message addressed to a recipient that’s located in your on-premises organization will be routed first through your Exchange Online organization and then delivered to the recipient in your on-premises organization. This route is recommended if you have more recipients in your Exchange Online organization than in your on-premises organization. This configuration option is required for Exchange Online Protection to provide scanning and blocking for spam.
- If you decide to keep your MX record pointed to your on-premises organization: All messages sent to any recipient in either organization will be routed through your on-premises organization first. A message addressed to a recipient that’s located in Exchange Online will be routed first through your on-premises organization and then delivered to the recipient in Exchange Online. This route can be helpful for organizations where you have compliance policies that require messages sent to and from an organization be examined by a journaling solution. If you pick this option, Exchange Online Protection will not be able to effectively scan for spam messages.
For more information, see Mail flow best practices for Exchange Online, Microsoft 365, and Office 365 (Overview).
As I only had one Edge Server and one AD Site in my Lab environment, I will select this one here.
On the Transport Certificate page below, select a certificate for the hybrid deployment configuration. This certificate will be used to authenticate secure mail transport between your on-premises Microsoft Exchange and Exchange Online organizations. This Certificate will be assigned to the Send Connector Outbound to Office 365 on the Edge Server. Later you also have to assign this certificate on the Receive Connector from the Edge Server.
The Send Connector Outbound to Office 365 from the Edge Server will be created during the Setup from the HCW.
The Subject Alternative Name (SAN) of this certificate must include the FQDN of your public onPrem Exchange Organization under which SMTP and HTTPS access (Client Access Server FQDN) is published to the internet.
So Exchange Online uses this FQDN to send bi-directional mail transport between the on-premises and Exchange Online organizations.
In most cases is this smtp.domain.tld or mail.domain.tld and in my case mail.braintesting.de
The certificate you choose, must be purchased from a trusted third-party certificate authority (CA) and installed in the Windows Certification Store on one of your Exchange Mailbox/Client Access servers, in order to be available to the HCW. Self-signed or any certificates generated by your internal organization CA, aren’t supported in hybrid mail transport.
In my case I purchased one from GoDaddy which is my preffered public CA.
You can create the certificate signing request directly on your Edge server.
New-ExchangeCertificate -GenerateRequest -Domainname mail.braintesting.de -PrivateKeyExportable $True >>c:\CSRreq.txt
-Domainname<MultiValuedProperty> –> you can add here multiple SANs separated with comma
mail.braintesting.de is the FQDN from the Exchange Organization, Single Namespace from the Client Access Servers and also the MX Record for inbound smtp traffic.
This FQDN is used from Office 365 (Exchange Online) to connect to our on-premise Exchange Organization. SMTP Port 25 for secure bi-directional mail transport and HTTPS Port 443 to access the Exchange Web Services (EWS) Url for Free/busy co-existence and mailbox migrations.
On Edge Servers including Exchange 2019, you mandatory need to install CAPI1/API (legacy) certificates, otherwise you will get an error. Using the New-ExchangeCertificate cmdlet will automatically create a CAPI1/API request.
After getting the signed certificate back from your public CA, import the the certificate as follows.
Import-ExchangeCertificate -FileData ([Byte]$(Get-Content -Path D:\Certificates\e63a0e6558a21e29.crt -Encoding byte -ReadCount 0))
Further you must assign the new certificate to the SMTP Service on the Edge Server.
Enable-ExchangeCertificate -Thumbprint FF62F9C09B57EC6180DFD9FDE3AB82504197E870 -Services SMTP
Overwrite/Replace the existing default SMTP certificate? NO !!!
Be careful with Edge Subscribe, if you replace default certificate for SMTP, you need resigning edge subscribe.
Assign certificates to Exchange Server services
TLS encryption for external SMTP client and server connections. Mutual TLS authentication between Exchange and other messaging servers.
When you assign a certificate to SMTP, you’re prompted to replace the default Exchange self-signed certificate that’s used to encrypt SMTP communication between internal Exchange servers. Typically, you don’t need to replace the default SMTP certificate.
So now after copying this certficate also from the Edge to one of my internal Mailbox Servers, I can select this Mailbox Server in order to be able to select this purchased certificate for the Send- and Receive Connector of my Edge Server.
Here I will select the new purchased certificate for the Edge Server with the FQDN mail.braintesting.de of my public Exchange Organization.
Before the HCW Wizard creates this Send Connector Outbound to Office 365 on the Edge Server, only the following default Send Connector are available on the Edge:
- EdgeSync – Frankfurt to Internet
(this Send Connector will send mails he first received on its default Receive Connector mailgate\Default internal receive connector MAILGATE from the internal Mailbox Servers outbound to the Internet with the scope *)
- EdgeSync – Inbound to Frankfurt
(this Send Connector will send mails he first received on its default Receive Connector mailgate\Default internal receive connector MAILGATE from the Internet inbound to the internal Mailbox Servers
After the HCW Wizard creates this Send Connector Outbound to Office 365 on the Edge Server, you can see the additional dedicated Send Connector for Office 365.
Under HomeMtaServerId, you can see that this Send Connector is also running on the Edge Server if you run the following Cmdlet on your Mailbox Server.
Get-SendConnector -Identity “Outbound to Office 365” | fl AddressSpaces, CloudServicesMailEnabled, Fqdn, HomeMTA, HomeMtaServerId, Identity, Name, Port, RequireTLS, TlsAuthlevel, TlsCertificateName, TlsDomain
Below you can see a screenshot from the product environment with two AD Sites (Stuttgart + Düsseldorf), in each site an edge server is deployed.
For hybrid configuration I configured both edge servers from each AD Site.
In this case also only one Outbound to Office 365 Sendconnector is created and will be associated to both edge servers.
On the Organization FQDN page, enter the fully qualified domain name of your on-premises organization.
This is the FQDN from the certificate you used for the Send Connector Outbound to Office 365 and Receive Connector of your Edge Server previously above.
This will configure the outbound mail connector to route mail from the the Exchange Online Protection (EOP) service to your Microsoft Exchange on-premises organization.
So I use the FQDN mail.braintesting.de.
Inbound and outbound HTTPS connections from and to Exchange Online are needed to support Free/busy co-existence and mailbox migrations. With Modern full Hybrid you only need the SMTP service be published to the internet, HTTPS inbound Access for Exchange Online provides here the HCW Agent which runs an application proxy service like the Azure Application Proxy. This agent initiates an outbound HTTPS tunnel to Exchange Online which will be used to access Exchange onPrem from Exchange Online.
Free/busy support needs to access the Exchange Web Services (EWS) URL. Also mailbox migration needs EWS and here the Mailbox Replication Service Proxy (MRS proxy service).
Enable the MRS Proxy endpoint for remote moves
MRS proxy service will be enabled by default from the Hybrid Configuration wizard (HCW).
At this point I think it does not harm to visualize the traffic flow between the Exchange onPrem and Exchange Online organization.
Traffic Flow Exchange Hybrid Classic Full
- Active Directory Hybrid with AAD Connect
Users will be synchronized from onPrem AD to Azure AD
- Direct SMTP – Connection between Exchange onPrem and Exchange Online. We can decide here to route SMTP traffic between both peers over the Exchange Edge Server in the perimeter network or directly between Exchange Online and the internal Exchange Mailbox Server and therefore jumping over the perimeter.
- HTTPS connections between Exchange onPrem Mailbox Server and Exchange Online and in both directions for Free/busy co-existence and mailbox migrations.
Well thanks for nothing 🙂 , HCW will stop working at configuring the Organization Configuration Transfer (OCT).
Examine the Logs under C:\Users\<user folder>\AppData\Roaming\Microsoft\Exchange Hybrid Configuration will show me that there are some problems with the login into outlook.office365.com. I suppose this is a timeout in the logged on session because of documenting the whole process takes time 🙂 .
The next try with the same settings works smoothly and so it seems that the session before had an timeout.
Organization Configuration Transfer (OCT)
OCT gives you the ability to replicate the Exchange 2010/2013/2016 configuration to Exchange online that includes:
Retention Policy, Retention Policy Tag, Data Loss Prevention Policies, Malware Filter Policy, Policy tip configuration, Address List, Active Sync Mailbox Policy, Mobile Device Mailbox Policy, Outlook on the Web Mailbox Policy, Active Sync Device Access Rule, Active Sync Organization Settings, Malware Filter Policy, Organization Config
This new update help organizations save time and effort as most of these configurations were done manually in Exchange Online after setting up the Exchange online hybrid to ensure the end user gets the similar experience when their mailbox is moved to Exchange online.
Admins usually perform these updates in Exchange online by using PowerShell or Exchange online Admin Center in Office 365.
With new version of Hybrid Organization Configuration Transfer tool, If object values are updated on-premises after they are moved to exchange online, admins can re-run organization configuration transfer to copy over the updated values from on-premises to exchange online. Admins will continue to control the process of keeping the objects in sync but with reduced effort by using organization configuration wizard.
Hybrid Organization Configuration transfer tool allows you to either update the objects in Exchange Online or to keep them as is. It also provides a script in the log folder with all the required previous settings so you can roll-back the changes.
To use the Hybrid Organization Configuration Transfer V2, ensure your Exchange 2010/2013/2016 is using the most recent or immediate previous release of Exchange Cumulative Update or Update Rollup.
So in order to complete the Hybrid configuration, I need to configure the Receive Connector from the Edge Server.
To determine the name of the internet facing connector I will run inside the Exchange Management Shell the cmdlet Get-ReceiveConnector on the Edge Server.
Configure the Receive connector
Set-ReceiveConnector -Identity “mailgate\Default internal receive connector MAILGATE” -TlsDomainCapabilities mail.protection.outlook.com:AcceptOorgProtocol -Fqdn ‘mail.braintesting.de’
Finally if not already assigned the certificate on the Receive Connector of the Edge Server, as mentioned the HCW will only assign it to the Send Connector, we need to assign it now in order to mailflow between Exchange onPrem and Exchange Online will work.
Determine the thumbprint of your responsible certificate and assign it to the Receive Connector, in my case:
$Cert = Get-ExchangeCertificate -Thumbprint FF62F9C09B57EC6180DFD9FDE3AB82504197E870 $TLSCertificateName = "<i>$($Cert.Issuer)<s>$($Cert.Subject)" Set-ReceiveConnector "MAILGATE\Default internal receive connector MAILGATE" -TlsCertificateName $TLSCertificateName
You can check it with the Get-ReceiveConnector | fl Cmdlet.
From now on secure-bi-directional hybrid mail transport between onPrem Exchange and Exchange Online should work.
If you not assign the certificate on the Receive Connector, Exchange Online cannot establish a secure TLS connection to your Edge Server and the connection will fail.
You will find more about troubleshooting Exchange Hybrid in Part 4 …
After finishing the Microsoft Office 365 Hybrid Configuration Wizard (HCW), to reconfigure your settings you can open the HCW again over the windows start menu or inside the Exchange admin center (EAC) under the hybrid menu .
Open directly doesn’t work on my Server and I have to start the HCW inside the EAC, and also here it doesn’t open each time and I had to repeat it a few times to click on modify 🙁 .
From now on your Exchange Organisation is extended to Office 365 and Exchange Online. You can now move users between onPrem and Exchange Online as used to from your onPrem environment like from one database to another or like when you configured coexistence between two Exchange Server versions and moved the users from the old environment to the new one.
Mail routing Exchange onPrem
Office 365 Exchange Hybrid Deployments Busting The Autodiscover Myth
In Part 3 … we will see how to moving user mailboxes from onPrem to Office 365 …