Edited: November 11, 2015
In a hybrid environment the on-premises Exchange organization (which can be either Exchange 2010 or Exchange 2013) is integrated with Exchange Online. In a hybrid configuration you basically create one ‘virtual’ Exchange organization with the following features:
- One cross-premises Address Book;
- Secure cross-premises mail flow;
- Cross-premises Free/Busy information, mail tips and out-of-office features;
- Seamless migration to Exchange Online and vice versa;
- No recreation of OST file;
- Automatic reconfiguration of Outlook profile;
- OWA URL Redirect.
To create a Hybrid environment you need at least one Exchange hybrid server on-premises. This can be an Exchange 2010 server but I always recommend using an Exchange 2013 server for this because of the improved hybrid connectivity in Exchange 2013. For redundancy purposes (and performance for larger environments) you better use multiple Exchange 2013 Hybrid servers.
Another prerequisite for creating a Hybrid environment is that you must have Directory Synchronization in place, so DirSync is used for synchronization user accounts, groups and contacts, all other communication is handled by the Exchange 2013 hybrid servers as shown in the following picture:
In a previous blog post (Implementing Directory Synchronization) I already explained how to implement Directory Synchronization so our lab environment is already up-and-running, and health when it comes to the on-premises Active Directory and Directory Synchronization.
If you’re running Exchange 2010 make sure that your Exchange 2010 are fully updated with Service Pack and (preferably) Update Rollup 10. If you’re running Exchange 2013 on-premises make sure that you have deployed Exchange 2013 CU9 in your environment. Please be aware that Microsoft only supports the latest version of Exchange 2013 in a hybrid environment!
Autodiscover and Outlook Anywhere
It happens every now and then that I working with a customer that’s using some Terminal Server solution to offer external access for employees and they’ve not deployed Outlook Anywhere on the Internet (and thus are not using Autodiscover externally).
For using Exchange Online and a hybrid environment this is an absolute showstopper. Autodiscover is needed for Exchange Online, but it is also needed in a hybrid environment for discovering mailboxes in your on-premises Exchange environment. Without Autodiscover it’s not possible to implement a hybrid environment.
Outlook Anywhere needs to be configured and externally available as well, since Outlook Anywhere is used to provide free/busy information, especially when using cross-premises availability services. I ran into this last year (end of 2014) where a customer had disabled Outlook Anywhere on a user level. Cross-premises free/busy information was working fine for regular users, but users that had Outlook Anywhere disabled (on-premises) free/busy was not working (please check this Disabled Outlook Anywhere causing free/busy issues blog for more information).
Exchange 2013 Hybrid Infrastructure
So, when all prerequisites are met, it’s time to start working on the Exchange 2013 Hybrid server. As explained earlier, the hybrid server is the server where the Hybrid Configuration Wizard is run.
The hybrid server can be a regular Exchange 2013 server that’s already available in your on-premises Exchange 2013 environment, or it can be a new Exchange 2013 server. This new server should be the same version of the other Exchange 2013 servers of course, and they have to be at the current Cumulative Update level.
In our example we’re going to install a dedicated hybrid server, configured with its own FQDN (hybrid.exchangelabs.nl). This FQDN will be used later on in the project for SMTP traffic between Exchange on-premises and Exchange Online and for migration traffic when moving Mailboxes between Exchange Online and Exchange On-Premises.
When it comes to configuring this hybrid server, all Virtual Directories are configured with the values one would use for the regular Exchange servers, like https://webmail.contoso.com/owa for OWA or https://webmail.contoso.com/ews/exchange.asmx for the Exchange web services. This way you can prevent unwanted results being returned by Autodiscover requests.
Your Exchange on-premises environment needs to be secured with SSL certificates. This is just another 3rd party certificate (Office 365 cannot deal with self-signed certificates or Active Directory CA issues certificates) configured with a CN=hybrid.contoso.com as shown in the following figure:
For secure messaging between your on-premises Exchange environment and Exchange online TLS is used, so the SMTP service on your Hybrid server (which is used for SMTP communications between on-premises and online) is using the SSL certificate as well. The SMTP Transport service therefore has to be bound to the SSL certificate mentioned in the previous paragraph and as shown in the following figure:
A bit simplified, but the environment now looks similar to the following figure:
Load balancing Exchange 2013 Hybrid servers
For redundancy purposes it’s best to have multiple Exchange 2013 Hybrid servers to distribute the load across these servers and to continue working when one server fails. You can use a (hardware) load balancer for this, but a better solution is to use multiple, single server, each with their own FQDN. In this case each server is externally accessible, independent of each other.
What’s the use of this compared to a load balancer? Once you start moving Mailboxes from Exchange 2013 on-premises to Exchange Online you have to define so called ‘endpoints’ in your on-premises environment. These endpoints are used by Exchange Online to access the Mailbox Replication Service (MRS) proxy running on your on-premises Exchange servers. With multiple FQDNs you can create multiple endpoints and spread the migration load this way. This will give a better result than when distribution move requests using a load balancer (strangely enough).
The good news is, you can use a wildcard certificate for this (even for the SMTP service) so there’s no need to purchase separate SSL certificates for each hybrid server.
Publishing Exchange Hybrid servers using TMG
It is possible to publish the Exchange hybrid servers using TMG (although I’m not a big fan of this) and personally I would not recommend following this path because of ending support for TMG, but the article How to Configure TMG for Office 365 (Exchange) Hybrid deployments provides a step-by-step approach on how to achieve this. Please note that this article is based on Exchange 2010.
Testing the Exchange 2013 Hybrid server
How do you test the Exchange 2013 Hybrid server? The easiest way is to logon to the Exchange Admin Center (http://hybrid.contoso.com/ecp) and see if you can manage your Exchange environment.
To test the Transport Service on the Exchange 2013 Hybrid server you can use the MX toolbox on the Internet, which you can find at http://mxtoolbox.com/diagnostic.aspx. Enter the FQDN of your Exchange 2013 Hybrid Server in the Mail Server textbox and click the Test Email Server button.
Please remember that for all other traffic the normal FQDNs and thus servers via webmail.contoso.com and autodiscover.contoso.com are used, also for communication between Exchange on-premises and Exchange Online.
SMTP Domains in Office 365
One last thing I want to mention, although it’s not a requirement at this stage is the use of SMTP domains. If you have multiple SMTP domains configured as Accepted Domains in your on-premises Exchange environment you should add these SMTP domains to your Office 365 tenant as well. If you forget to do this (the Hybrid Configuration Wizard as explained in the next blog will continue without this step) you can run into issue when moving Mailboxen from Exchange on-premises to Exchange Online as described in an earlier blog post: https://jaapwesselius.com/2014/09/08/you-cant-use-the-domain-because-its-not-an-accepted-domain/
So, this is a good time to add (and validate) your additional domains in Office 365.
Summary
In this blogpost I explained a bit more about an Exchange Hybrid scenario, where your on-premises Exchange environment (2010 or 2013) is integrated in Exchange Online through the use of one (or more) Exchange 2013 Hybrid servers.
There are a few prerequisites to be met, but if all is configured properly it’s time to continue with creating the actual Exchange Hybrid configuration, as explained in the next blog post.
Jaap Wesselius 
Hi Jaap, one question regarding Outlooky Anywhere. You mean explizit the client side (Outlook itself), right?
Cheers, Alex
LikeLike
Hi Alex,
No, I’m afraid not. I mean the Outlook Anywhere service on the Exchange servers themselves. You have to configure Outlook Anywhere on the Exchange servers and have it available on the Internet.
Thanks – Jaap
LikeLike
Hi Jaap,
Great post, as usual 🙂
It’s my understanding that using hybrid.domain.com to seperate hybrid traffic is prefered, however in simple deployments, if certificates are valid, using the regalur names (ex. webmail.domain.com) pose no problem, or do I miss something?
Bart
LikeLike
Hi Bart,
You’re right, you can use the regular Exchange servers for this, but I typically recommend using a dedicated Hybrid server.
Thanks,
Jaap
LikeLiked by 1 person
Hello
Thank you, excellent post. Question about the reverse proxy, if we have a TMG in place with Exchange 2010 and want to continue using with Exchange hybrid (duly noted your recommendations to not use it and agree with 🙂 ). Do we need to change the publishing rules to include Exchange 2013 hybrid servers?
Trying to understand what changes do we need on reverse proxy if we introduce Exchange 2013 hybrid servers in Exchange 2010 org.
LikeLike
Hi,
I was in a similar situation last year where I was helping a customer to a hybrid scenario with Exchange 2010. Implementing an Exchange 2013 server was not possible at that time so we had to use 2010 Hybrid. And TMG was in the mix as well. I used this article to configure TMG for the hybrid connectivity (dedicated rule for this, next to the regular Exchange 2010 publishing rules): https://community.office365.com/en-us/w/exchange/1042.how-to-configure-tmg-for-office-365-exchange-hybrid-deployments
Thanks,
Jaap
LikeLike
sorry, one last question. Can NLB be used for load balancing the hybrid servers ?
LikeLike
Sure, but better is two have two dedicated hybrid servers (hybrid01.contoso.com and hybrid02.contoso.com). This way you can define multiple migration endpoints (this will be the topic of my next blog, but due to holiday season I’m a bit late 🙂
LikeLike
Thank you sir for the quick replies and all the awesome posts, appreciate it.
LikeLike
Great article.
I have scenario described below and would truly appreciate your suggestion.
Hybrid deployment to migrate Exchange 2007 mailboxes to O365:
2# hybrid server behind the WNLB:
WNLB Private IP- 10.1.1.10
HB01- Exchange 2013 CAS+MB – Private IP- 10.1.1.20
HB02- Exchange 2013 CAS+MB – Private IP- 10.1.1.21
webmail.domain.com – Point to Public IP – 12.12.10.120 NAT to WNLB IP (10.1.1.10)
autodiscover.domain.com- Point to Public IP – 12.12.10.120 NAT to WNLB IP (10.1.1.10)
If I use ‘whatsmyip’ on each hybrid server, they show different public IP (other than of webmail.domain.com 12.12.10.120)
configured hybrid successfully (Only haven’t configure OAuth). Every hybrid feature is working, but I CAN NOT create MRS End points(webmail.domain.com) to move mailboxes.
Also tried this: created Public DNS records for each hybrid servers, FQDN of each server pointed to public IP and internal server responding with same public IP but still can’t create end point using FQDN of servers.
LikeLike
Hi,
It’s difficult to troubleshoot remotely, but I would try with only one hybrid server, just to rule out any issues with WNLB. If this works, you can start adding the 2nd server again and see what’s happening.
Thanks Jaap
LikeLike
goo article but i have question regarding the separate hybrid namespace. I’ve set mine up that way but i have been getting mixed results about the virtual directories on the hybrids. Are you saying leave them the way they are which is pointing to the existing exchange servers?
LikeLike
Hi,
I have been struggling with this as well (due to conflicting articles etc), but yes, I’m saying to use existing URL’s and point to existing Exchange server (i.e. webmail.contoso.com)
LikeLike
Hi Jaap,
So when installing exchange 2010 with different fqdn do you mean when installing the new exchange 2010 server on the internet facing CAS tab. Add a different fqdn there, then in the existing environment after installation change the webmail, outlook anywhere,ews, ecp, active sync external url’s to the names that the pre-existing exchange 2010 servers are using?
LikeLike
Hi,
autodiscover.contoso.com and webmail.contoso.com are still used, you can use an additional FQDN like hybrid.contoso.com, or mrs.contoso.com (I see this one a lot) or even o365mail.contoso.com for the communication with Office 365. Beware that you don’t mess up namespaces, I’ve seen situations where autodiscover returned something like mrs.contoso.com/ews/exchange.asmx where it should have been webmail.contoso.com/ews/exchange.asmx. Outlook doesn’t like that, and you’re users neither 😉
LikeLike
Hi Jaap,
Thanks for the quick response. Ok, so I’m installing a new exchange 2010 server into the existing environment (eg. mail.contoso.com) and just adding a different DNS “A” record and IP address (eg. o365.contoso.com) to use for mailbox migrations to Office 365.
LikeLike
Hi Jaap,
As I understand, when you have two exchange servers (2010 and 2013) ,you can setup the azure connect to the 2013 exchange server. Is it allowed to also migrate the 2010 server true the 2013 server?
Regards, Perry
LikeLike
Azure AD Connect is a separate server (service), independent of the Exchange server. When it comes to migrating, I assume you’re talking about hybrid? You can build a hybrid solution on Exchange 2010 using the new Hybrid Configuration Wizard, no need to install a separate Exchange 2013 server. If you have an Exchange 2010/2013 coexistence scenario, all access will be through the Exchange 2013 servers, including migration traffic.
LikeLike
The New FQDN hybird.domain.com only apply for communicate to exchange online and it is a must FQDN for this design?
For normal design , we can use mailbox roles to keep use webmail.contoso.com right?
Thanks.
LikeLike
Yes, it must be a FQDN, but you can also use the normal design, webmail.contoso.com
LikeLike
Hi Jaap
if if i have separate hybrid servers, do i need to run the hcw on each one separately ?
Thanks
gary
LikeLike
I am a bit confused by your remarkt ‘separate hybrid server’. A hybrid server is an Exchange server where you run the HCW, that’s all. You only run the HCW once. Yes, you can have multiple servers communicating with Exchange Online, but these are typically the servers already in use.
LikeLike
thanks for the reply, i think i get you, you run the hcw once and select which servers you want to include in the configuration. we have an existing hybrid 2013 server (hybrid.company.com) and would like to add a second one for redundancy. Our mailboxes are on exchange 2010 servers, and our autodiscover record is pointing to hybrid.company.com, just wondering will adding the 2nd hybrid to the mix cause any issues ?
LikeLike
I’m currently working with an Exchange 2010 customer, where I’ve configured only the Exchange 2010 servers for hybrid usage. But when you use a separate ‘hybrid server’ with an additional FQDN like hybrid.company.com you can add multiple servers after a load balancer. This works fine. You can also add multiple servers with multiple FQDN’s (hybrid, hybrid1, hybrid2.company.com), primary reason would be to configure multiple endpoints. Can be useful when you have to migrate 10.000 or more mailboxes.
LikeLike
‘you can also add multiple servers with multiple fdqn’s (hybrid, hybrid1…’ how ? i guess i can’t use the hcw to do this ? sorry, still trying to get my head around this !
LikeLike
This has nothing to do with the hybrid configuration wizard. You can add multiple servers with multiple FQDN’s, and add each and every server with its FQDN as a ‘migration endpoint’. This way you can use multiple servers with multiple endpoints for moving mailboxes (and speed up the migration process dramatically)
LikeLike
So Outlook Anywhere is required at the server level and also at the mailbox level with set-casmailbox -MAPIBlockOutlookRpcHttp $false ?
LikeLike
That is correct, yes.
LikeLike
Thanks for the great article.
I already have a hybrid setup with exchange 2010 but the mailboxes ars still onprem. I am going to add two new exchange 2016 to start the migration. The exchange 2016 will be added 1st time to the environment. Old hybrid was setup using Hybrid.domain.com and I can also see the most of vertual directory is using same Hybrid.domain.com on this hybrid server except SCP and Outlook Anywhere. but the rest of the cas servers are using mail.domain.com.
What should i be setting up on this new exchange 2016 server and then re-run the HCW. I think it must be mail.domain.com otherwise users will be impacted. But I have to use Hybrid.domain.com as organization FQDN while running the HCW??….
LikeLike
Personally I should not add the 2016 servers at this point, but move the mailboxes using the existing 2010 hybrid. When done upgrade the Exchange 2010 to 2016, rerun the HCW using the same namespaces as before and you should be good.
LikeLike
Hi Jaap. Nice article. I know this is 5 years old but this process is presumably still the same! We are an on-prem org with a sudden need for hybrid and i am trying to figure it all out quickly. I think i understand the gist of it but am uncomfortable about opening the firewall directly to an Exchange server for autodiscover and other web services. We have always used 2fa for webmail and blocked off other Exchange web services. So my question: can i limit connections to my hybrid server to only office 365 IP addresses? I have created a firewall rule based on the MS Exchange Online IP address API but my hopes are not high because the Exchange Connectivity Analyser is failing.
Many thanks
Brian
LikeLike
Hi Brian,
it should be no problem to restrict this, i have several customers doing this. I assume you have seen this: https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges
I am not sure thought if the Remote Connectivity Analyzer is in the same IP space as Exchange Online, it might well be another IP range.
But in the end it is well possible.
Cheers, Jaap
LikeLike
Thanks very much Jaap.
I am using the powershell example from here:
https://docs.microsoft.com/en-us/office365/enterprise/office-365-ip-web-service
I am assuming it is the same thing.
Since reading your article i have decided to install a new Exchange server, set it up with the same urls as our other servers and then run the wizard on the new server.
I will choose “enable centralised mail transport” because i want our on-prem servers to handle all outbound and inbound email after the hybrid transition.
The new hybrid server will handle smtp and mrs and our current exchange servers will deal with web services via our kemp load balancer (locked down with office 365 ips described above).
Sorry to be so long winded but i would be really grateful if such an experienced dude as yourself could tell me if all of this makes sense!
Regards
Brian
Smtp and mrs tra
LikeLike