Follow us on Twitter
Follow us on YouTube
Would you like to suggest a topic for the Exchange team to blog about? Send suggestions to us.
With Exchange Server 2013 and Exchange Online in Office 365 for Enterprises, customers continue to have the flexibility of moving to the cloud on their terms – whether switching fully to the cloud via a cut-over migration, migrating over time with a staged migration, or managing mailboxes both on-premises and online with a hybrid Exchange deployment. This unique hybrid option allows customers to move to the cloud at their own pace, while leveraging the sharing of calendar free/busy information, hosting mailbox archives in the cloud with Exchange Online Archiving, and enabling users in both organizations to connect and work seamlessly with each other.
Since the introduction of hybrid deployments in Exchange 2010 SP1, connecting your on-premises Exchange organization to an Office 365 organization using a hybrid deployment has matured from an exhaustive set of manual configuration steps to a simple, six question wizard. Starting with Exchange 2010 SP1, administrators wanting to connect with an Exchange Online organization hosted in Office 365 needed to manually configure the bulk of the hybrid deployment parameters, including the configuration of the MRS Proxy service, organization relationships, remote domains, virtual directories and email address policies. This process was cumbersome and rife with the opportunity for Exchange administrators to make configuration mistakes. In order to simplify the hybrid deployment process and reduce the likelihood of configuration errors, we introduced the Hybrid Configuration wizard with the release of Exchange 2010 SP2. The wizard automated the bulk of the hybrid configuration process and significantly reduced the likelihood of hybrid configuration errors. However, the wizard didn’t address some common deployment scenarios such as deploying Edge Transport servers in the on-premises organization and needed to address the architectural changes associated with the release of Exchange Server 2013.
Exchange Server 2013 includes improved support for Office 365, both in terms of making it easier to deploy and simpler to manage. The first of a two part post, this post will cover the changes we made to the hybrid deployment experience. A second post discussing the hybrid management improvements will follow shortly.
Note: Exchange 2013 Preview server-based hybrid deployments with an Office 365 Preview tenant isn’t supported during the preview period and shouldn’t be used in production environments. Organizations wanting to deploy Exchange 2013 server-based hybrid deployments in production environments should wait until the updated Office 365 service is publicly released.
Exchange Server 2013 provides the following hybrid deployment improvements:
Now let’s a take a quick tour of the new hybrid deployment process and the new Exchange Administration Center (EAC) user interface. Although the user interface has significant changes, the requirements and sequence of tasks is very similar to Exchange 2010 SP2 from a process perspective.
Before you start the hybrid deployment process with the Hybrid Configuration wizard, you’ll need the following pieces in place before you can start your hybrid deployment:
As the Office 365 service continues to improve and add new functionality, it’s important to understand the impact that Office 365 version changes have for Exchange 2013 hybrid deployments. For native Exchange Server 2013 organizations, as well as Exchange 2007 and Exchange 2010 organizations that plan to deploy Exchange Server 2013 servers, your Office 365 tenant must be version 15.0.000.00 or higher to configure a hybrid deployment. Exchange Server 2013 Client Access and Mailbox servers will only support hybrid functionality with the new version of Office 365. There are checks built in to Exchange Server 2013 setup and hybrid configuration wizard to ensure you don’t end up in a bad state.
The updated Office 365 service will also continue to support Exchange 2010 organizations that have previously configured a hybrid deployment, as well as Exchange 2003 and Exchange 2007 organizations that have added Exchange 2010 servers to support a hybrid deployment. However, some specific administrative functions will require updates and more details will be announced as they are released.
For organizations planning a new hybrid deployment, we recommend that they deploy Exchange Server 2013 in order to leverage the improved deployment process and management experience.
Note: Office 365 Preview tenants are not supported for existing Exchange Server 2010 SP2 hybrid deployments during the service preview period. Full support for Exchange Server 2010 hybrid deployments will be supported with future updates to Exchange Server 2010 and when the Office 365 service is publicly released.
From an Exchange on-premises configuration standpoint, you’ll need to perform the following deployment tasks:
For a comprehensive list of all Exchange Server 2013 hybrid deployment requirements, see Hybrid Deployment Prerequisites
Once these tasks are complete, run the Hybrid Configuration wizard to complete the configuration of your federation trust, organization relationships and mail flow connectors.
The Hybrid Configuration wizard can be found here within Exchange Administration Center:
After starting the Hybrid Configuration wizard, you’ll move through several steps.
First, you’ll select the federated and accepted domains for the hybrid deployment configuration. You should select the primary SMTP domain for your organization and any other accepted domains that will be used in the hybrid deployment. Because the Hybrid Configuration wizard is now adaptive, you may not be presented with this step. If you have only one on-premises accepted domain added to your Office 365 tenant, the domain is automatically selected and the step is skipped in the wizard.
Next, you may be presented with domain proof token information for the domains you’ve selected to include in the hybrid deployment. You’ll need to create a TXT record on your public DNS to prove ownership of this domain. The Hybrid Configuration wizard will skip this step if the domain has already been federated.
Next, you’ll select which server role you want to configure for bi-directional secure mail transport between the on-premises and Exchange Online organizations. You also have the option to enable centralized transport for outbound Exchange Online mail transport. Depending on how you answer, the wizard will either configure an Exchange Server 2013 Mailbox or Exchange 2010 Edge Transport server in your on-premises organization. For this post, we’ll select configuring a Client Access and Mailbox servers.
Next, you’ll select one or more on-premises Client Access servers you want to configure for bi-directional secure mail transport between the on-premises Exchange and Exchange Online organizations.
Next, you’ll select one or more on-premises Mailbox servers you want to configure for bi-directional secure mail transport between the on-premises Exchange and Exchange Online organizations.
Next, you’ll select the digital certificate to use for secure mail transport. This certificate must be issued by a third-party Certificate Authority (CA) installed on the server(s) selected in the previous steps.
Next, you’ll enter the externally accessible FQDN for the on-premises Client Access server(s). The EOP service in Office 365 uses this FQDN to configure the service connectors for secure mail transport between your Exchange organizations.
Finally, you’ll enter the credentials for accounts for both your on-premises and Office 365 tenant. Both of these accounts must be members of the Organization Management role groups.
That’s it! The Hybrid Configuration wizard uses this information and automatically configures your on-premises and Exchange Online organizations for hybrid.
After completion, users in both organizations can access each other’s free/busy calendar information, send email between the organizations securely and administrators can move user mailboxes between the two organizations.
The Update Hybrid Configuration log now separates each hybrid configuration step into a clearly delineated section to simplify review or troubleshooting. The log also now identifies where each hybrid configuration task is performed, either in the on-premises Exchange organization or in the Exchange Online organization.
The Hybrid Configuration Engine now finds email address policies (EAP) that match the domains you select within the Hybrid Configuration wizard and updates them to include an email address based on a domain automatically generated by the Office 365 tenant service. This domain, known as the coexistence domain, is a domain created for each Office 365 tenant in the format of <your domain>.mail.onmicrosoft.com domain. For example, a coexistence domain for Contoso would be “contoso.mail.onmicrosoft.com” after the contoso.com domain was added to Office 365 as a federated domain.
What we’ve learned from Exchange 2010 SP2 customers was that some hybrid customers were manually editing email addresses to include the coexistence domain without going through Exchange tools and doing this without excluding the user from email address policies. This means that if the email address policy logic was triggered, which can happen inadvertently through a number of different means in Exchange, the user’s primary SMTP address may have been changed to match the policy template. These changes were unexpected for some of these customers and would often cause issues with hybrid mail transport. We’ve made a change in Exchange Server 2013 to support a new switch which allows the Hybrid Configuration Engine to add the extra email address for the coexistence domain for users without changing the primary SMTP address. This will occur even if your organization has manually edited user email addresses. We will be following up with another blog post to discuss this topic in more depth as we want to ensure customers know how to avoid this state when using manual methods to edit email addresses.
Another improvement that has come direct from customer feedback is support for specifying an “Autodiscover domain”. By specifying an Autodiscover domain, you can control which hybrid domain is used for Office 365 to on-premises federated Autodiscover requests. This is particularly useful for those organizations with lots of domains and/or changing domain lists. It allows you to publish Autodiscover for a particular domain and not need to publish them all, or change as you add more domains.
Hybrid deployment scenarios for Exchange 2013 deployments, as well as for legacy Exchange 2007 and 2010 organizations deploying Exchange 2013 servers, will be supported in the release of the new Exchange 2013 Deployment Assistant in early 2013. Look for announcements about the new Deployment Assistant in future posts.
If you’re looking for more information on Exchange 2013 Hybrid Deployments, click here.
We hope that you’re as excited as we are about the new Hybrid Configuration wizard changes. Look for more articles soon covering topics such as troubleshooting, multi-forest support, and removing a hybrid configuration.
Ben Appleby, Robert Mazzoli and the Hybrid Configuration Wizard team