Exchange 2010 hybrid and Edge Transport Server
In two previous blog posts I explained how to setup an Exchange 2010 hybrid environment. In these blog posts I used the Exchange 2010 (multi-role) server for the hybrid configuration, so both the Exchange Web Services (used for free/busy, Mailbox Replication Service, OOF, mail tips) and the SMTP connection between Exchange Online and Exchange 2010.
Now that Exchange 2010 end of support is getting closer (less than a year!) I get more questions regarding the move from Exchange 2010 to Exchange Online. And several questions include the use of an Exchange 2010 Edge Transport server in front of the Exchange 2010 multi-role server.
This configuration will look something like this:
Inbound mail from Internet is getting through Exchange Online Protection and when the mailbox is still on Exchange 2010 it is routed via the Edge Transport Server to the internal Exchange organization. Outbound mail is leaving the organization via the Edge Transport server or via Exchange Online Protection, depending of the location of the mailbox.
The challenge when configuring this in Exchange 2010 is shown in the following screenshot:
Compared to running the HCW on Exchange 2013 or Exchange 2016 there’s no option to configure the Edge Transport server for secure mail transport in Exchange 2010!!
The only option right now is to run the Hybrid Configuration Wizard, configure it using the Client Access and Mailbox servers option, but use the data for the Edge Transport where needed.
So, run the Hybrid Configuration Wizard, and when you need to enter the public IP address of the transport servers, enter the Public IP address of the Edge Transport server and not the public IP address of the load balancer VIP pointing to the Exchange 2010 internal servers). In my environment, the webmail.inframan.nl points to 126.96.36.199 and the Edge Transport Server smtphost.inframan.nl points to 188.8.131.52. This is the IP address I am going to use as shown in the following screenshot:
The next step is to select the certificate that’s used on the Edge Transport Server. By default, the HCW will only look at the internal Exchange 2010 server, so it won’t find any certificate installed on the Edge Transport server. To overcome this, I have imported the certificate of the Edge Transport Server in the certificate store of the internal Exchange 2010 server used by the HCW. In the HWC, click on the drop down box and select the certificate of the Edge Transport server, in my environment the smtphost.inframan.nl certificate:
The last step is where the FQDN of the organization needs to be entered. I have a lot of discussion here because most admins want to enter something like ‘hybrid.domain.com’, but the FQDN of the transport server needs to be entered here, so in my environment this is the FQDN of the Edge Transport Server, i.e. smtphost.inframan.nl. This FQDN is used (together with the certificate information) to create a Send Connector from Exchange Online to the Edge Transport server.
Finish the Hybrid Configuration Wizard. It will be configured in Exchange 2010 and in Exchange Online and after a short time you can close the HCW:
Now, when looking at the Exchange Management Console you can see the Send Connector from Exchange 2010 to Exchange Online. It is configured with the FQDN smtphost.inframan.nl as expected, but the source server of the Send Connector is still the internal Hub Transport server as shown in the following screen shot:
Remove the Hub Transport server entry and add the Edge Transport server instead. If you have an Edge Synchronization in place you will see it immediately when you click the Add button.
In Exchange Online, the Receive Connector that’s created will check for any certificate with a wildcard like name, so the smtphost.inframan.nl certificate will automatically be accepted. The Send Connector is also created correctly. The FQDN of the Edge Transport server is used as the server to route message to, and the CN of the certificate that was selected in the HCW is also configured as shown in the following screenshot:
We’re almost there. The only thing that needs to be done is to configure the Receive Connector on the Edge Transport Server for TLS from Exchange Online. You should have already configured the Edge Transport Server with the correct 3rd party certificate and when setting up an inbound connection it should use the 3rd party certificate. You can test this using the https://checktls.com tool online.
On the Edge Transport server, execute the following command in the Exchange Management Shell:
Get-ReceiveConnector "smtphost\Default internal receive connector SMTPHOST" | Set-ReceiveConnector -Fqdn smtphost.inframan.nl -TlsDomainCapabilities mail.protection.outlook.com:AcceptOorgProtocol
This will make sure the cross-premises email will be treated as internal email (SCL=-1). If you omit this step, there’s always the risk the email will be treated as external (I’ve seen SCL=5 in my environment) and will end up in the user’s Junk Email Folder.
When configuring an Exchange 2010 hybrid configuration it is not possible to configure an Edge Transport Server in the Hybrid Configuration Wizard. It is possible to configure this in the HCW for Exchange 2013 and Exchange 2016, but for Exchange 2010 this needs some manual changes.
In this blogpost I showed you the steps needed to configure an Edge Transport Server for secure messaging between Exchange Online and Exchange 2010. When configured this way cross-premises email will be seen as internal email and thus treated accordingly.
8 thoughts on “Moving from Exchange 2010 to Office 365 Part III”
“I have a lot of discussion here because most admins want to enter something like ‘hybrid.domain.com’, but the FQDN of the transport server needs to be entered here.”
In your situation yes but when customers uses a 3rd party mail/spam device where MX points then you should use an alternative IP/DNS to deliver mail from EOP directly to the Transport server.
But most likely these customers do not have an Edge Transport server 😉
But you are right, and this scenario where EOP is sending mail directly to the Transport server is in an earlier blogpost. if I’m correct we discussed this some time ago too.
You are correct, those should not have an Edge Transport 🙂 But i thought you ment to set it like that in a general way. Confusion out of the way! Yes on another post we discussed the direct delivery and certificate usage.
Just wanted to hear your opinion. We are currently running Exchange 2010. We are considering two options; hybrid O365 or upgrade to Exchange 2016/2019. Hybrid O365 has my preference. But as the eos is getting near and I read that you are not a fan of introducing a exchange 2016 server into an 2010 environment what would you do?
1. First create the hybrid exchange 2010\O365 environment.
Second upgrade 2010 components to 2016/2019.
2. The other way around.
Love to here from you.
The preferred and recommended way is to create an Exchange 2010 hybrid environment, move all mailboxes to Exchange Online and then upgrade your Exchange 2010 environment to Exchange 2016. If no mailboxes remain on-premises you can use the ‘hybrid license’ but be aware this license is only for Exchange 2016 and NOT for Exchange 2019.
Hi Jaap, thanks for the post.
Can we change the organization fqdn while introducing exchange 2016 to the current exchange 2010 hybrid environment?
What are all the changes made by this fqdn? Just the mail flow or it will also change the VD urls on hybrid servers?
I get this question quite a lot, and my preference is to change all settings (especially when you have x number of FQDN’s in combination with L4 load balancing) before you start moving. Not only in a hybrid environment, but also when moving from Exchange 2010 to Exchange 2016.
Hi Jaap, thank you for the blog post. I have a few queries re the migration from Exchange 2010 to 2016 and the migration of the O365 connectors that delivers emails from/to on-prem servers.
Is it recommended to use the same FQND as the ones setup on Exchange 2010 and if so, will there be an impact on the email flow when changing the DNS records to point to Exchange 2016 or is it recommended to use a different FQDN when running the new HCW on 2016? Will this process create a separate connector?
Just having a few concerns on the impact on the email flow and I don’t have access to lab environment to test.