Hybrid deployment best practices


Many Office 365 customers are using our hybrid deployment option since it offers the most flexible migration process, the best coexistence story, and the most seamless onboarding user experience. However, even with all of this flexibility, a few wrong choices in the planning and deployment phase could cause you to have a delayed migration, unsupported configuration or have poor experience. This article will help you make the best choices for your hybrid configuration so you can avoid some common mistakes. For more information on Exchange hybrid go here.

image
* As of this writing, Exchange 2016 is in Preview. It is not meant for production use. You would never install that in your production environments… right?

Ensure your on-premises Exchange Deployment is healthy

Some of our best guidance for configuring hybrid comes from the Exchange Deployment Assistant (EDA), however the Exchange Deployment Assistant separates the on-premises configuration from the hybrid configuration. There is an unwritten assumption that is made in our hybrid guidance that you have already properly deployed and completed the coexistence process with the current versions of Exchange in your on-premises environment. You really should ensure the existing environment is a healthy environment prior to starting Exchange hybrid configuration steps.

This means that if the newest version of Exchange in your environment is Exchange 2010, you need to deploy the right amount of 2010 servers to handle the normal connection and mail flow load for all of your on-premises mailboxes. Similarly, if the latest version in your environment is Exchange 2013, you need to deploy enough 2013 servers to handle the load. For more information on on-premises Exchange Server sizing go here.

Note: There is always an exception to the rule. In this case the exception is mail flow. There is a possibility that you may configure hybrid so all mail flows through your on-premises environment even after you move most of your mailboxes to Exchange Online. You may even have some applications that rely on the on-premises Exchange servers for SMTP relay. All of this needs to be accounted for and some extra thought may need to go into your sizing plans for these scenarios. Currently, our toolset for planning and sizing your mail routing environments do not cover these more complex scenarios.

If you think about a typical hybrid deployment, on day one there are essentially no mailboxes in the cloud. Therefore, you most likely have an environment that can handle all of the current on-premises workflow. Then as you move mailboxes to Exchange Online the load on the on-premises servers reduces since much of the client connectivity and mail flow tasks are now handed off to Exchange Online. The minor amount of processing power that is needed on-premises for things like cross premises free busy for an Exchange Online mailbox after it is moved will not come close to the demands of an on-premises mailbox, for example.

Should we have a hybrid specific URL?

We have seen deployments where a decision is made to keep the existing Mail.Contoso.com and Autodiscover.Contoso.com pointing to a bank of Exchange 2010 servers and have a new hybrid URL, such as hybrid.Contoso.com, pointing to a couple of Exchange 2013 servers. This is an example of an environment that did not introduce Exchange 2013 in a recommended way. Let’s forget about hybrid for a second. When you introduce Exchange 2013 into an environment you should configure coexistence in a supported way. This means that you install enough Exchange 2013 servers to handle the proxy load for all on-premises mailboxes and point the external URL to the latest version of Exchange in the site. Again, deploy the latest version properly before you enter a hybrid configuration.

Keep Exchange up to date

The Cumulative Update (CU), Rollup, and Service Packs you have running on the on-premises server should also not be overlooked. Under normal circumstances we support you being no more than two updates behind the currently released update for Exchange; however, for hybrid environments, we are stricter and you should not be more than one build behind. If the latest update is Exchange 2013 CU9, then you must have either Exchange 2013 CU9 or CU8 to be considered in a supported state. We are stricter with our hybrid requirements because of how tightly the on-premises and Exchange Online environments will be coupled together. For more information on our available updates please go here.

Some might ask: “Can I keep just my hybrid server up to date?” The answer: there is no such thing as a “hybrid server.” (More on that in a minute.) What this question is really asking is: “Can I just update the server were I plan to run the Hybrid Configuration Wizard (HCW) from?” The answer to that is “No.” As we move through this post, you will see how entering into a hybrid world means most of your servers are playing a part and communicating cross premises. In order for you to have a seamless experience and be supported, you need your whole environment to be up-to-date, not just a specific server or two.

If you have a healthy updated on-premises configuration, you will have a proper foundation for introducing a Hybrid configuration into your messaging environment in a supported and optimal way.

There is no such thing as a ‘hybrid server’

We often hear people say “I am going to deploy a hybrid server,” thinking they will designate specific three or four servers as “hybrid servers.” However, they fail to realize that hybrid is a set of organization-wide configurations and the server where the HCW is run from is just there to initiate these configurations.

To explain this, let’s briefly cover a free/busy scenario. When an on-premises user creates a meeting request and looks up a cloud user’s free/busy information, the request will go to the EWS URL returned from Autodiscover (step 1 below) and that server will facilitate the request by initiating the Availability service to talk to the O365 service (step 2 below). At this point, that could be ANY server in the environment. This means that when you configure hybrid, all 2010 CAS, 2013 Mailbox, and 2016 servers (when this will be supported) in the environment could be facilitating a federated free/busy request. There is no reasonable way to direct outbound federated free/busy requests to a particular set of servers.

image
From on-premises to EXO

Let’s look at the reverse scenario and explain what happens when a cloud user looks up an on-premises user’s free/busy information. In this scenario, the EXO server would perform an Autodiscover request to determine the on-premises EWS endpoint (step 1 below) and any server that responds to that Autodiscover.Consoto.com or Mail.Contoso.com endpoints would be responsible for facilitating the Autodiscover or free/busy request (step 2 below). The thing to keep in mind is that these are the same endpoints for all of the on-premises users for things like client connectivity, so you would not want to limit them to one or two servers in a larger environment. In short, you should deploy Exchange properly into your environment, then do your hybrid configuration.

image
From EXO to on-premises

Part of this confusion could be because in the HCW we ask users for CAS and Mailbox servers. The reason we ask for the CAS is so that the receive connectors on these servers can be configured. The reason we ask for the Mailbox is to ensure that we properly configure the send connectors. Selecting those servers is not selecting your “Hybrid servers” it is just for mail flow control explicitly. We do not have any concrete recommendation around which servers or how many of them should be added for mail flow purposes. There are just too many factors with mail flow such as seat count, migration schedules, geographies, etc.

Be sure to choose the correct version of Exchange

The Hybrid Configuration Wizard can be run from Exchange 2010, 2013, and soon 2016 so the question is often asked: “What version should I run the HCW from?” Let’s go through some of the decisions that will have to be made to help answer this.

Do you have Exchange 2003?

If Exchange 2003 is in your environment, then your only option for going hybrid will be to use Exchange 2010. This means that you would need to ensure that you have properly deployed and sized the Exchange 2010 environment, and then you can run the hybrid configuration process.

Is Exchange 2007 the oldest version you have deployed?

If you have Exchange 2007, and you do not already have Exchange 2010 deployed then we would recommend you properly deploy Exchange 2013, then deploy hybrid. This will give you the largest feature set, and since you have to introduce a newer version of Exchange, you should deploy a version that is supported under mainstream support.

Have you deployed Exchange 2010?

If this is the case, you need to ask yourself if Exchange 2010 fits your needs or if you need the features of Exchange 2013. Deploying hybrid with Exchange 2013 allows for features like cross-premises e-discovery, enhanced secure mail, or OAuth federation support. If these features are not important to you, then you can stick with Exchange 2010 on-premises and deploy hybrid.

In the event you want to upgrade your on-premises environment to Exchange 2013, you would need to deploy Exchange 2013 following our best practices guidance and deploy enough Exchange 2013 servers to handle all of the on-premises traffic. This includes going through the proper steps to size and deploy Exchange 2013 for your on-premises environment and following the guidance for properly setting up hybrid configuration. Often customers will use the Exchange deployment assistant two times for this. First time to introduce Exchange 2013 into the Exchange 2010 environment and the second time to introduce hybrid.

Is your newest deployed version Exchange 2013? Are you planning for Multi-Org hybrid?

Aside from the OAuth configuration previously mentioned, Multi-Org hybrid requires at least one Exchange 2013 (or later, when this is supported) server on-premises in every forest that will be entering into the multi forest hybrid configuration. HCW for Exchange 2010 does not have the proper logic to handle the naming conventions used for connectors and organization relationships. For more information on Multi-Forest hybrid go here.

A simpler story is ahead for Exchange 2016

When we release Exchange 2016 the deployment guidance for coexistence with Exchange 2013 will be a lot simpler than in the past. You will no longer have to move your URL’s to the newest version of Exchange, and instead, will be able to add one or two Exchange 2016 servers to the pool of servers that respond to the Autodiscover.contoso.com and Mail.Contoso.com endpoints. This means you will not have to stand up enough servers running the latest version to handle all traffic on day one.

image

While this will not benefit customers that are running older versions of Exchange, customers who are upgrading from Exchange 2013 to Exchange 2016 will go through a really easy and seamless process.

In summary

Taking a bit of time to cleanup your current infrastructure and understand your options for your hybrid deployment can save you a lot of time and aggravation later.

Lou Mandich, Scott Roberts, Ross Smith IV, Scott Landry, Timothy Heeney

Comments (5)
  1. Thanks for sharing these design considerations. Would like some clarification on the following:

    "We have seen deployments where a decision is made to keep the existing Mail.Contoso.com and Autodiscover.Contoso.com pointing to a bank of Exchange 2010 servers and have a new hybrid URL, such as hybrid.Contoso.com, pointing to a couple of Exchange 2013 servers.
    This is an example of an environment that did not introduce Exchange 2013 in a recommended way."

    This is precisely how the Deployment Assistant recommends building out a hybrid deployment when the existing environment is 2010 and 2013 is chosen for the hybrid servers. Will the DA be updated based on this new guidance, or does this guidance trump the DA,
    or….?

    "Let’s forget about hybrid for a second. When you introduce Exchange 2013 into an environment you should configure coexistence in a supported way. This means that you install enough Exchange 2013 servers to handle the proxy load for all on-premises mailboxes
    and point the external URL to the latest version of Exchange in the site. Again, deploy the latest version properly before you enter a hybrid configuration."

    Is there an obvious benefit to moving the existing namespace to 2013 (other than reducing certificate SAN requirements)? Introducing a new hybrid.contoso.com namespace seems like it’s less impactful on end users since they can continue to point to the existing
    namespace, and Autodiscover internally and externally can be re-pointed to hybrid.contoso.com to meet the HCW requirements.

  2. @Varol
    Thanks for pointing out that flawed information in that path of the Exchange Deployment assistant, I will work with our EDA team to get that information corrected so that it matches the proper guidance from this blog.

    The benefit to moving the External URL to point to the latest in site version of Exchange that is properly deployed is…
    1. You most likely already have your environment properly sized with the currently deployed version of Exchange
    2. Exchange (up to Exchange 2013) was design to properly proxy traffic as long as the external endpoint is pointing at the latest version of Exchange
    3. Deploying Exchange in the proper way, meaning following our guidance to deploy Exchange 2013 into an existing 2010 environment will be much less impactful than attempting to work around the designed coexistence logic we have in product
    4. In addition, there are many customers that will end up keeping a good portion of users on-premises, in that case they may want to move some of the users to Exchange 2013 on-premises. If you deployed correctly from the beginning there is no extra changes
    that would need to take place… you just move mailboxes
    5. All of the validation that we do for Hybrid features is done against on-premises environments that are deployed in the expected way.

    Again, thanks for the comments…
    -Tim

  3. Tim,

    Appreciate the quick response and for working to get the EDA updated. I wanted to follow up on #3 and #4 – hopefully others are benefiting from this discussion as well :)

    "3. Deploying Exchange in the proper way, meaning following our guidance to deploy Exchange 2013 into an existing 2010 environment will be much less impactful than attempting to work around the designed coexistence logic we have in product"

    Could you please elaborate further? In my mind, this seems more impactful as we must move the existing namespace to 2013, meaning the modification of existing DNS records and firewall rules.. and in the case of existing 2007, the creation of a new legacy namespace.
    After the change, users will see a new OWA login page, which may be a concern if end user communications have not been sent out. With a separate hybrid namespace, nothing changes from an existing DNS/firewall/end user perspective except we repoint Autodiscover
    at 2013. When a user is moved to EXO, Autodiscover reconfigures Outlook and they use a new URL for OWA.

    "4. In addition, there are many customers that will end up keeping a good portion of users on-premises, in that case they may want to move some of the users to Exchange 2013 on-premises. If you deployed correctly from the beginning there is no extra changes
    that would need to take place… you just move mailboxes"

    Agreed this may be true of larger enterprises, although it’s not something we run into too often.. for these customers, it’d be important to point out the licensing requirements during planning, as I believe the free hybrid license terms of use do not allow
    for the migration of production mailboxes onto the hybrid servers.

    Thanks again.

  4. @Varol

    Moving the existing namespace from 2010 to 2013 can certainly have an impact, which is why you needs to first determine which version of Exchange you should be running the HCW from. If the users are on Exchange 2010 then maybe 2010 is the right version to use
    so, why even bring in Exchange 2013. If you however require an 2013 specific feature it will be less disruptive and more predictable to deploy Exchange the way it was designed to work. If you deploy Exchange in a way that we do not validate you run the risk
    of things not working unexpectedly. This has happened in the past and it could certainly happen in the future.

    Again if you look at one of the points of the article, there is no such thing as a Hybrid Server, just Exchange servers. There are proper ways to deploy Exchange so coexistence works in the most predictable way, that is the point we are trying to get across.

  5. Azure-Amjad says:

    Great Article, thank you

Comments are closed.