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