Exchange 2013 Hybrid Prerequisites (Part I)

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 ( 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 for OWA or 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 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 ( 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 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 and 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:

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.

17 thoughts on “Exchange 2013 Hybrid Prerequisites (Part I)”

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


  1. Hi Jaap,
    Great post, as usual 🙂
    It’s my understanding that using to seperate hybrid traffic is prefered, however in simple deployments, if certificates are valid, using the regalur names (ex. pose no problem, or do I miss something?


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


    1. 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):



    1. Sure, but better is two have two dedicated hybrid servers ( and 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 🙂


  3. 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-
    HB01- Exchange 2013 CAS+MB – Private IP-
    HB02- Exchange 2013 CAS+MB – Private IP- – Point to Public IP – NAT to WNLB IP ( Point to Public IP – NAT to WNLB IP (

    If I use ‘whatsmyip’ on each hybrid server, they show different public IP (other than of

    configured hybrid successfully (Only haven’t configure OAuth). Every hybrid feature is working, but I CAN NOT create MRS End points( 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.


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


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


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


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s