If you're already running Exchange 2010 or higher, you don't have a plethora of options if you want to migrate mailboxes to Office 365. But that's not necessarily a bad thing; it gives you rich coexistence during the migration,
Think of it as a transition, rather than a migration. Performed correctly, using a hybrid Exchange installation for a migration has the smallest effect on end users when compared to a staged or cutover migration. It also makes use of the skills you already have.
That's not to say a hybrid Exchange environment is always appropriate; small organizations can benefit from the simplicity of a cutover or staged migration. If you're not running on-premises Exchange, look at products from vendors like MigrationWiz and Quest.
Hybrid challenges for Exchange 2007 and Exchange 2003 organizations
The proper steps to implement a hybrid Exchange environment for Exchange 2003 or 2007 are parallel to an Exchange 2010 migration. People often refer to the "hybrid" server as if it's sitting on the edge of your environment and only used for Office 365. In reality, it's just an Exchange server.
This is where the challenge comes in. You'll need to migrate front-end client access services like AutoDiscover, OWA, EWS or ActiveSync for the hybrid functions. When you're looking at what needs to be done, check out this article on the Exchange Team Blog. You only have one option if you're using Exchange 2003: You need to use Exchange 2010 SP3. If your organization is using Exchange 2007, then you have a few options with Exchange 2010 SP3 or Exchange 2013 CU1.
It's tempting to use the latest version, but you may want to consider Exchange 2010 SP3 first if you're using forms-based authentication within Exchange 2007. This comes down to coexistence; when users login with Exchange 2010 SP3 acting as the "front" for Outlook Web App, they'll automatically be redirected to Exchange 2007's legacy namespace without being prompted again for a password. With Exchange 2013 CU1, the user will be prompted for the password a second time when they are redirected to Exchange 2007, thus requiring a double login.
Migration challenges for Exchange 2010 organizations
There's often confusion around Exchange 2010 and hybrid migrations. One of the most common questions asked is if you need a hybrid server with Exchange 2010. The answer is no.
All Exchange 2010 SP3 Client Access and Hub Transport servers have the code needed to act as hybrid servers. Unless you're looking to migrate to on-premises Exchange 2013, you don't need Exchange 2013 CU1 for a hybrid Exchange migration. It doesn't offer any additional coexistence features.
One area to consider is whether you have some minimal additional capacity; this requires you to support out-of-hours mailbox moves and federated sharing. Most times, you won't have any because you'll move mailboxes to the cloud and free up resources.
Questions may arise as to whether Exchange 2010 SP3 is stable enough to implement in your organization and where it needs to be. Exchange 2010 SP3 is stable, though there have been reports of issues with PDF and WAV files in unusual circumstances that affect a small number of customers. Microsoft has a fix available. You don't need to implement Exchange across your organization. If Exchange is spread across multiple sites, you'll only need to immediately upgrade your Internet-facing sites to SP3.
Hybrid challenges for Wave 14 hybrid tenants and others
For organizations already using hybrid features on Exchange Online, you will be upgraded to the latest version of Exchange Online whether you like it or not. You'll have the chance to postpone this once, but the upgrade will happen.
In Exchange, you will need to upgrade to Exchange 2010 SP3. You can do this before your tenant is upgraded to Wave 15. After the upgrade, you'll need to rerun the Hybrid Configuration Wizard (HCW), so be aware of subsequent changes you made to hybrid-specific configuration, including modifications to receive connectors or organizational relationships.
Whether you use Exchange 2003 through Exchange 2013, there are common challenges all organizations need to know about when implementing a hybrid environment. Here are a few of the main ones.
External connectivity. External connectivity using trusted third-party certificates need to work well against your Exchange organization. If you use self-signed certificates and you haven't properly configured your External URLs for services such as Exchange Web Services, then you'll certainly have problems. Make sure AutoDiscover and Exchange Web Services work correctly by testing the connectivity.
Legacy federated delegation certificates. If you're a long-term Exchange 2010 organization and set up Federated Sharing before Exchange 2010 SP1, then you may also need to remove the Federation configuration. There's an easy way to know if this is the case. Prior to SP1, a third-party certificate was used rather than a self-signed certificate. This older version used a different Microsoft Federation Gateway, so if the certificate has expired, you may need to contact Microsoft support to assist with removal.
Large numbers of accepted domains. Organizations with many accepted domains may also experience issues. The HCW will attempt to use name-based AutoDiscover against each domain listed in the hybrid configuration, and it won't take into account SRV records you may be using for these domains. Exchange 2013 has a feature to allow you to select a single domain for the HCW. You can update the hybrid configuration by specifying a prefix of autod: against your preferred domain:
Set-HybridConfiguration -Domain "domain.com, autod:primary.com"
Pre-authentication. For organizations making use of TMG
and similar software like F5 and KEMP load balancers, you may need to determine if you use
pre-authentication. Pre-authentication ensures that a user authenticates at the firewall or load
balancer with a username and password before they connect to Exchange.
Exchange Online uses the Federation Gateway for availability and calendar sharing, and this does not need or support pre-authentication because it uses Web Services Security for authentication. You can disable pre-authentication for the /AutoDiscover and /EWS sub directories or learn how to implement a rule.
SSL offload. You may be able to successfully run the HCW, but you won't be able to
migrate mailboxes that have it enabled. Exchange 2013 doesn't support SSL offload, so it shouldn't
be a worry.
Many larger Exchange 2010 organizations use SSL offload. The architecture sizing may require this to perform adequately, so disabling it may not be an option. A workaround is to publish a second Virtual IP (VIP) with a different HTTPS name with SSL offload disabled. You'll enter this second name when you use the Remote Move wizard to migrate mailboxes.
SMTP mail flow. Before you start, understand how mail routing works within the organization. The HCW will create new send and receive connectors to communicate with Exchange online, and these are essential for maintaining the illusion that people are communicating in a single Exchange organization.
It's fairly easy to ensure the HCW's Exchange send connector for outbound mail flow can communicate directly with Exchange Online, but the receive connector may present some challenges. For organizations that already filter mail somewhere else, it may not be possible to expose the external IP address connecting in from Office 365 directly to Exchange. Instead, the firewall or load balancer in between may be presenting its IP address to Exchange. If it's the latter, the solution is often to use a new Load Balancer VIP for inbound Office 365 mail flow. You may also need to configure the receive connector to listen on a different internal port so it will widen the range of IP addresses it responds on.
We've looked at some of the challenges you may face when implementing a hybrid Exchange configuration against the new version of Office 365. This isn't an exhaustive list of everything you might encounter, but these answers to common problems can help you make sure to avoid common pitfalls and make the right decisions when getting ready to migrate to Exchange Online.
About the author:
Steve Goodman is an Exchange MVP and works as a technical architect for one of the U.K.'s leading Microsoft Gold partners, Phoenix IT Group. Goodman has worked in the IT industry for 14 years and has worked extensively with Microsoft Exchange since version 5.5.
This was first published in August 2013