In this article series, we have been taking a look at the evolution of Exchange Online migrations since the early BPOS days up until today.
In the previous article in this series, we took a closer look at the remaining migration options we had and still have at our disposal, which are the Cutover Exchange migration and the at-the-time brand-new and comprehensive Exchange hybrid deployment migration option.
In this, the fourth part of our series, we will continue where we left off in Part 3. Specifically, we will take a look at the direction where Exchange hybrid deployment migration option has moved.
Let’s get going…
Exchange Server 2010 hybrid configuration wizard arrives
We have already talked about the Exchange hybrid deployment option that was made available with the Exchange Server 2010 RTM on-premises version released back in November 2009. This was a great new way to set up full coexistence between your on-premises Exchange environment and Exchange Online. However, the deployment and configuration of an Exchange hybrid deployment was a very time-consuming task that also kept Microsoft Customer Support Services very busy, as many customers ran into issues with their Exchange hybrid deployment.
For this reason, the Exchange team spent a lot of resources trying to come up with a simpler and less error-prone process. This resulted in a hybrid configuration wizard (HCW) that was included with Exchange Server 2010 Service Pack 2 released back in 2011, two years after the Exchange 2010 RTM release.
The HCW provided us with a relatively simple wizard that guided the Exchange administrator or consultant through a set of configuration steps. First, we had to create the hybrid configuration object itself. We create this under the Organization in the Exchange Management Console.
Once created, we could right-click on it and select manage “Manage Hybrid Configuration,” which brought us to the wizard depicted below.
Using this wizard, we could establish an Exchange hybrid deployment in a much easier fashion than with pre-Exchange 2010 SP2, where we had to go through all the steps necessary for an Exchange hybrid deployment one at a time. We just had to create the TXT record necessary for the federation trust, add the domains that needed to be part of the hybrid deployment, specify the client access and Hub Transport servers to be used for sharing and mailbox moves, ensure that a trusted third-party certificate with the required names was in place, configure the mail flow settings for FOPE (now known as EOP), and the wizard would do all required configuration for us.
Note: For pure nostalgia and the complete steps for deploying an Exchange 2010 based hybrid configuration using the Exchange 2010 SP2 HCW (with all the figures included), check out this articles series.
Behind all the wizards, there is a kind of engine with all the required logic. This is no different for the HCW. Here, we have the hybrid configuration engine, which takes all the input from the wizard and performs the actual configuration steps in the on-premises environment and in the Exchange Online tenant. The configuration information is stored in the hybrid configuration object in Active Directory.
The hybrid configuration engine uses a “desired state” approach, meaning that it will take the input from the wizard and then match it with any settings already defined in the hybrid configuration object. This means that it only will do any necessary configuration updates, so if you are running an update to the hybrid configuration and the input already matches with what is configured, no writes will be made the matched settings.
The following diagram gives a great high-level overview of how the hybrid configuration engine works.
Note: More details on the hybrid configuration engine can be found over on Microsoft TechNet.
As you can see, the arrival of the HCW was a very welcomed feature. With that said, though, things were still not perfect. We have lost count of how many times the HCW failed during the hundreds of Exchange hybrid deployments we have been engaged with over the years. Good thing is we had a HCW log that usually was pretty good for identifying what went wrong when the HCW errored out during one of the configuration steps.
Fortunately, the development in the Exchange hybrid deployment space didn’t stop here. Lots of stuff have been done since the Exchange 2010 SP2 days, and guess what? We will look much closer at these changes/improvements during the upcoming parts of this articles series.
If you would like to read the other parts in this article series, here are the links:
