In my previous blogpost, I’ve discussed the prerequisites for moving from Exchange 2010 to Office 365 when using Directory Synchronization (using Azure AD Connect). In this blogpost I’ll discuss how to create an Exchange 2010 hybrid environment.
Exchange 2010 Hybrid
Now that Directory Synchronization is in place using Azure AD Connect we can focus on connecting the on-premises Exchange environment to Exchange Online, this a called an Exchange Hybrid Configuration.
Hybrid configurations can consist of Exchange 2010, Exchange 2013 or Exchange 2016 or a combination of versions, so it is possible to have an Exchange 2010 and Exchange 2013 coexistence scenario on-premises, and connect this to Exchange Online. However, when using multiple versions of Exchange in a Hybrid configuration there’s always add complexity, and when configured incorrectly you can get unexpected results. Therefore, I typically recommend using only one version, so if you’re running Exchange 2010 on-premises, there’s no need to add an Exchange 2013 or Exchange 2016 server to your configuration, just as a ‘hybrid server’. Despite what other people tell you, there’s no need to add a newer version, and Exchange 2010 Hybrid is fully supported by Microsoft. Better is to create an Exchange 2010 hybrid environment, and when the mailboxes (or most the mailboxes) are moved to Office 365 upgrade your existing Exchange 2010 environment to Exchange 2016. But that might be an interesting topic for a future blog post 
.
Basically, we will create the following configuration (again, there is no Exchange 2016 server installed in the existing organization):
Figure 14. Exchange 2010 hybrid configuration.
In February 2016 Microsoft released a new Office 365 Hybrid Configuration Wizard (HCW) for Exchange 2010, replacing the old HCW that was initiated from the Exchange Management Console. To start the new Hybrid Configuration Wizard logon to the Exchange 2010 server and go to https://aka.ms/HybridWizard to download and start the new HCW. This will automatically download the new HCW from Office 365, click Install to start the new HCW.
This will start the Hybrid Configuration Wizard that will configure the Hybrid configuration, or long term coexistence configuration between Exchange 2010 and Office 365. When the HCW wizard appears click Next to start the wizard.
The wizard will look in Active Directory for installed Exchange servers, and it will try to detect the optimal Exchange server to configure. Since Inframan has only one Exchange server it will automatically select this server.
When you click on the Office 365 Exchange Online dropdown box you’ll see an overview of all available Office 365 environments. For our environment, we should select the default Office 365 Worldwide. Click next to continue.
In the next window, enter the credentials of your Office 365 tenant administrator and if needed, change the credentials of your on-premises domain administrator and click next to continue.
The HCW will now login to both your on-premises Active Directory and your Office 365 tenant. If all goes well, you’ll see six green dots for Exchange and Office 365 (including ‘Succeeded’). Click next to continue.
Now there are two options:
- Minimal Hybrid Configuration – This is a very minimal hybrid configuration that can be used for moving your mailboxes from Exchange 2010 to Exchange Online in a short amount of time, where a coexistence scenario is not needed. This can be used for smaller organizations that want to move to Office 365 at all, but keep Directory Synchronization in place.
- Full Hybrid Configuration – As the name implies this is a true hybrid configuration with a long term coexistence scenario. You can easily move mailboxes back and forth, but also use secure mail between Exchange on-premises and Exchange online, use free/busy information cross-premises and use stuff like out-of-office information and mailtips.
For the Inframan organization (which requires a long-term coexistence) select Full Hybrid Configuration and click next to continue.
If you want to implement a hybrid configuration, a trust is needed between Exchange Online and Exchange on-premises. This is not something like a forest- or domain-trust as you see in Active Directory on-premises, but this is a Federation Trust. Before a Federation Trust is implemented, Microsoft must make sure you own the domain you want Microsoft to federate with (i.e. the Inframan.nl domain). Click enable to continue and start the domain validation process.
The validation process is similar to the validation process when adding a new domain to Office 365, but instead of a simple ‘MS=ms123456’ text string a much more complex string needs to be added to public DNS. Click to copy to clipboard option to copy the text string to the clipboard of your computer. This contains the TXT records that needs to be added to your public DNS, and will be something like:
GEfLGFqgs3Tf9WJCCqLnrSH62Y81RG1QeRCTUWhbMxH1lWrWSK+CJJG92neNz6etQNUqoaLSHJqd6huQlDvEKA==
You can use NSLOOKUP to check if the new TXT record is available on the internet, and when it is check the I have created a TXT record for each token in DNS checkbox and click verify domain ownership.
The next window will be about configuring your Client Access servers and Mailbox servers for secure mail transport. You can leave this option default (typical), and in this scenario mail from Exchange Online to the Internet will be sent directly by the Exchange Online mail servers. If you select the Enable centralized mail transport option, you can configure the mail flow to use Exchange on-premises. In this scenario mail from Exchange Online sent to the Internet will always be sent via your Exchange on-premises organization. This lets you have full control over your inbound and outbound SMTP mail flow. One of my customers is actually doing this, and they perform DKIM signing on all outbound messages on-premises, even when messages originate from Exchange Online.
For Inframan we don’t use the centralized mail transport, click next to continue.
For secure mail between Exchange Online and Exchange on-premises we must select a Hub Transport server (in Exchange 2010) or a Mailbox server (in Exchange 2013/2016) to configure with Send and Receive Connectors. For mutual TLS, the Exchange servers also need to be configured with a valid 3rd party SSL certificate.
Again, in Inframan we only have one Exchange 2010 server which we can select using the drop-down box. Select the server and click next to continue.
Enter the public IP address that Exchange on-premises uses for inbound and outbound mail flow and click next to continue.
The HCW will no try to detect the SSL certificates on the Exchange server. One of these servers need to be used to enable mutual TLS. In this Exchange 2010 server I only have one SSL certificate with CN=webmail.inframan.nl, the autodiscover.inframan.nl domain name is a Subject Alternative Name on this certificate.
Select this SSL certificate and click next to continue.
Enter the FQDN of your Exchange organization (i.e. the FQDN Exchange Online will use to connect to your Exchange environment) and click next to continue.
The HCW has now gathered enough information to configure the hybrid configuration. Click update to start the configuration of the hybrid configuration.
The status of the configuration is shown on the console:
After a couple of minutes the hybrid configuration wizard has finished. If all goes well no errors are generated and you can rate your experiences at the end of the wizard. If you are extremely satisfied you can rate five stars, and click close to finish the HCW.
You have now successfully configured a hybrid configuration with Exchange 2010 on-premises and Exchange Online. And… without using an Exchange 2016 server
In my next blog I will discuss testing the hybrid configuration , and will discuss moving mailboxes from Exchange 2010 to Exchange Online.
Jaap Wesselius 
Hi Jaap,
In the HCW you select a transport certificate to enable mutual TLS.
One of the steps in the HCW is to enter the public IP address and IP address of the on-premises server, this information is used for inbound and outbound mail flow, secured by the transport certificate selected during the HCW.
I can remember I once entered an IP during the HCW and selected an (public) SAN certificate as transport certificate and had problems with mail flow due to Office 365 not accepting the TLS
Then I changed the IP in the HCW to an FQDN not matching the (public) SAN certificate and had the same error.
So does the FQDN you enter during the HCW need to be on the transport certificate?
LikeLike
The wrong certificate is being returned in your scenario (I’ve seen this happen as well). HCW creates a new receive connector with the fqdn you enter (i.e. webmail.contoso.com), this should match the CN on the public certificate. The receive connector is configured with source IP addresses from Microsoft. Exchange Online tries to access your environment, the Microsoft IP will make sure the request accesses the right receive connector and based on the FQDN the right certificate is used.
When you have a reverse proxy or load balancer with transparancy enabled, the IP address presented to Exchange is always the IP address of the load balancer. The request will always access the wrong (default) receive connector and the self-signed certificate is returned. MTLS will now fail because of this self-signed certificate. Reconfigure the load balancer or reverse proxy and you should be good to go.
LikeLike
So the FQDN you enter during the HCW for hybrid mail flow needs to be on the certificate?
This can be a problem when customer use an antispam device and the MX points to this antispam device. We then always create an extra DNS record (example hybrid.contoso.com) for FQDN in HCW mail flow. We then use an alternate public ip and open port 25 and point it directly to the Exchange server (bypassing the antispam device). But this setup requires to have hybrid.contoso.com on the certificate?
So if customer has a SAN certificate the customer needs to add it as SAN entrty on their current SAN certificate?!
LikeLike
Yes, you need the FQDN on the certificate for authentication to occur. I’m 99% sure it has to be the CN and cannot be a SAN entry (because of the authentication).
This can be an issue, you’re right. Adding an extra DNS record is an option. In my example I’m not using the regular inbound mailservers (Edge Transport) but using the webmail entry instead. This is a separate VIP on my F5. It can also be another entry, but I try to avoid the name ‘hybrid’ because it tends to derail all Exchange admins. But if you use something like O365mail.contoso.com for the MTLS connection between Contoso and Office 365, this needs to be the CN on the certificate. In this case I use a regular SSL certificate (no multidomain, SAN certificate or something).
LikeLike
Jaap,
Thanks for prompt reply and information.
May I ask how you do this if a 3rd party antispam is used? Do you create a new FQDN o365mail.contoso.com on a new/seperate public ip and open port 25 and NAT it to Exchange server?
And if a customer has SAN certificate with CN webmail.contoso.com and SAN entry autodiscover.contoso.com do you buy new new single label o365mail.contoso.com certificate and select that one during HCW or reissue the SAN and change the CN to o365mail.contoso.com ?
LikeLike
Using a 3rd party antispam solution between your Exchange en Exchange Online to create a hybrid environment is not supported. I think you can get it to work, but I haven’t tried it yet. Definitely not supported.
There are several options. Last time (couple of weeks ago) we created a new VIP on the load balancer, same IP but different port (25 instead of 443) and used this with a new certificate like o365.contoso.com. Port 443 was used for webmail.contoso.com and autodiscover.contoso.com. So we ended up with two certificates. I don’t argue with customers about a certificate. A discussing with me about certificate costs more in hourly rate than buying a new SSL certificate straight away 🙂
And yes, during HCW the new FQDN (with certificate) was used.
In theory you should be able to reissue the certificate and have the CN changed to o365mail.contoso.com with webmail.contoso.com and autodiscover.contoso.com as a SAN entry, but that’s also something I haven’t tried.
LikeLike
Hi Jaap,
I did a double check at a customer where I implemented Exchange 2010 hybrid. During HCW I used FQDN hybridmail.contoso.com and selected their SAN certificate where this FQDN was added as a SAN entry. Mail flow works o365exchange ( just tested it 🙂 )
Also Microsoft states that it can be a SAN entry and does not need to be the CN. See article at https://technet.microsoft.com/en-us/library/hh563848(v=exchg.141).aspx
LikeLike
I’m a bit suprised that it works with a SAN entry, but hey, you’re never too old to learn 🙂
Thanks for the comments!
LikeLike
Hello Jaaap .Thx you for your article .I’m preparing a project for a client and your explanation is the most clear for me . Now i have some questions after doing this configuration no need to change anything on the DNS to confirm that hybrid is working perfect? is there any point of this guide where the current mail flow can be interrupt . I ask the question because knowing that i will be working for a customer i dont want him to be impacted by my configuration
LikeLike
Hello Gaston, O365 is just connecting using autodiscover and the FQDN you enter during the hybrid configuration wizard. Of course you have to test the results by moving a couple of testmailboxes to Exchange Online and see if everything still works. When it comes to mailflow, you have to be sure you configure this correctly, use the right FQDN and that there’s a direct connection between Exchange Online and Exchange 2010. But, when you don’t move anything and don’t change any DNS records (like SPF or MX) you won’t break any mailflow.
LikeLike
Hello Jaap,
I followed your guideline and everything went well (except i have chosen the minimal configuration). Thanks for that!
We have a small setup with 20 mailboxes, so this should work. But do you also have a guideline for migration the mailboxes? And can you tell me if the migration will also move the public folders?
LikeLike
Hi,
Thanks for your feedback. Public Folders is a different migration, very similar to the PF migration from Exchange 2010 to Exchange 2016, so export the information, edit the information and import the information in O365. Then move the Public Folders.
LikeLike
Ok cool, thanks! And what about the migration itself after using the HCW? Do i have to use the “normal” migration batch from the exchange online admin center? If yes, i will probably have to use the cut-over migration, right? At the moment its greyed, probably because of the active Azure AD Sync. Do you have any documentation on this?
LikeLike
To be honest…. I haven’t done a single thing with the minimal hybrid so I don’t know. If I’m correct the minimal hybrid is just for moving mailboxes without the other stuff in hybrid. Migrations are started from EAC in Exchange Online, and you have to select the first option since it’s just using the MRS. But again, I haven’t been doing anything yet with minimal. Currently working on an Exchange 2010 hybrid upgrade to Exchange 2016 (25,000 mailboxes, so full hybrid 🙂
LikeLike
Yeah, it said that the minimal configuration is best for only migration. But thats enough for me. I think you mean with “the first option” the remote move requests, right?
But thanks again for your input… i will do some testing with the remote-move-request and hopefully it works.
LikeLike
you’re welcome, and let me know how things work out, thanks
LikeLike
Hello Jaap ,
I’m migrating an exchange 2010 to office 365 and I’m a little confused .
Since it’s a small customer , about 30 users, I’d opt for the minimal hybrid . So I tried and the wizard ended with no error . before changing the MX record to point EOP I tried to manually test by sending an email to a user that still is on exchange 2010 but got a denied error .
So I’m confused about the mail flow in such scenario
thanks
LikeLike
sorry for my late reply, I have been travelling last couple of weeks. What error do you get in your scenario?
LikeLike
Hi Japp, first off great articles! Is there a third part to this article showing how you moved the mailboxes and then decommissioned the on-premise exchange server? Thanks!
LikeLike
No not really, I’m sorry. This is something that’s still on my plate to finish sometime
LikeLike
Hi- why does the HCW need to re-validate the domains if those domains have been validated in O365? Thx.
LikeLike
it is not a validation like when adding to Office 365, this is for validating the organization relationship
LikeLike