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.
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.