In the last topic of this chapter, we walk you through the concept of a hybrid deployment. A hybrid configuration is a setup in which an on-premises Exchange server is configured in a rich coexistence scenario with Exchange online (Office 365).
There are many reasons why a company might decide to build a hybrid deployment, including:
Migrations to Office 365 over a longer period of time
Taking benefit of cloud features such as Exchange Online Archives
Splitting workloads between Exchange on-premises and Exchange online, for instance to save resources on-premises
When considering hybrid scenarios in Exchange Server 2013 and Office 365, an important aspect of the design phase is going through a feature comparison between both platforms, as well as going through some of the specific characteristics when both platforms are being integrated. A good starting point to understand what is supported and what is not, would be to go through the Exchange Online service descriptions which describe the features and possibilities in Exchange Online:
http://technet.microsoft.com/en-us/library/office-365-service-descriptions.aspx
The power of the hybrid configuration in Exchange Server 2013 lies in the new Hybrid Configuration Wizard (HCW). People that have been working with Exchange Server 2010 before might recognize the name, as it was first introduced with Exchange Server 2010 Service Pack 2.
Before Exchange 2010 Service Pack 2, setting up a hybrid configuration was one hell of a job. There were about a million things to check and to go through before it could even get to work. The first release of the Hybrid Configuration Wizard consolidated all these steps into a wizard, and the overall process of setting up a hybrid was brought back to about six steps. Although far from ideal, this was a huge improvement compared to before!
One drawback of the Hybrid Configuration Wizard in Exchange 2010, however, was its complexity. There were still too many things one had to check and the wizard itself was statically. Every time you ran the HCW, it would re-set all the settings it had already set before.
The new Hybrid Configuration Wizard in Exchange 2013 is different in many ways. Although essentially it is designed to configure the hybrid setup, it does so very elegantly: the new wizard is dynamically built, which means that it will take into account how your environment is set up. When going through the wizard multiple times, it will not try to reset settings that were set up before. As a result, it usually finishes a lot faster than its predecessor. Last but not least, the HCW in Exchange 2013 also performs more tasks. Before, you were still required to perform some manual steps outside of the wizard, which are now included.
There are many components that come together to make a hybrid deployment work. At the foundation of a hybrid configuration, we can distinguish three building blocks:
Secure mail flow
Federation
Cross-premises mailbox moves
Secure mail flow between your premises and the cloud ensures that messages sent from one place to the other are seen as being company internal. In fact, in a hybrid scenario, you have two different Exchange organizations that, without any configuration, would not know they are somehow related to the same company.
To ensure secure mail flow, TLS capabilities in Exchange are leveraged (and enforced) to validate the receiver's domain and encrypt the traffic. This allows, amongst other things, the preservation of certain headers responsible for marking a message as company-internal.
Exchange federation is the part that allows both worlds to talk to each other in a secure way. There are two types of federation used. Firstly, there's the federated delegation with the Microsoft Federation Gateway (MFG) and secondly there's the Exchange federation which is, for example, used to do Free/Busy lookups.
Delegated federation is used whenever a connection is made from one environment to the other. For example, when an on-premises user requests Free/Busy information from a user whose mailbox is in the cloud, the on-premises Exchange server will first request a token from the Microsoft Federation Gateway. That token is then used to authenticate in Office 365. Given Office 365 also trusts the Federation Gateway, the token is accepted and Free/Busy information can be exchanged. In fact, the Microsoft Federation Gateway is a sort of security broker in between both environments. This allows companies to set up a trust once with the MFG and then re-use that trust for subsequent relationships with other Exchange organizations or their own Office 365 tenant.
Of course, having a trust with the MFG alone isn't enough. On top of that, an Organization Relationship between both Exchange organizations is needed to validate that either parties trust each other on an Exchange level. Consider the preceding example. After the on-premises Exchange server made the connection to Office 365 and the token was validated, the Exchange online will first check if there is an existing Organization Relationship between itself and the on-premises Exchange organization. If one is found, Free/Busy information is sent over. If not, the request will be denied and an error occurs.
Although the preceding description is rather simplistic, it does reflect in a high-level way how the interaction works between both environments. Of course, there are still other things at play like how Autodiscover is used in this scenario. However, we won't go into detail here. The topic deserves a book in its own right and is beyond the scope of this book.
The third building block of a hybrid configuration is the ability to transparently move mailboxes between your on-premises organization and Office 365. By leveraging the Mailbox replication service, mailboxes can be moved using native mailbox moves in Exchange. This has many benefits over other migration methods. Firstly, there is no need for an OST resynchronization after the move. Secondly, when migrating from Exchange 2007, 2010 or 2013, mailbox moves happen online. This means that a user can continue working in his/her mailbox during the move. Only during the final stage (where the switchover occurs) the user is required to restart Outlook.