Exchange Hybrid Deployment and Migration with Office 365

  • Article

Applies to: Office 365 for enterprises

If you are currently managing an on-premises e-mail system and now are deploying Microsoft Office 365 for enterprises, you need to plan carefully. First, consider your long-term goals:

  • If your long-term goal is to maintain mailboxes both in your on-premises organization and in the cloud, you should deploy Exchange in your on-premises organization in what is called a hybrid deployment.
    A hybrid deployment requires Microsoft Exchange Server 2010. However, a full Exchange 2010 organization isn’t required to enable a hybrid deployment. You can install a minimal Exchange 2010 hybrid server in an existing Exchange 2003 or Exchange 2007 organization.
  • If your long-term goal is to move all mailboxes to the cloud, you must evaluate your current on-premises e-mail infrastructure and select the migration tool and method that works best for your organization. There are several methods to migrate all mailboxes to Office 365 for enterprises. Each method has advantages and disadvantages for administrators and users, and each method has specific requirements and dependencies.

This topic is designed to help you understand all the options and plan your deployment. It explains the terminology and describes the deployment options and the tools that are included with Exchange Online and Office 365 for enterprises as follows:

  • Terminology: The secret decoder ring
  • Primary long-term e-mail deployment options
  • Additional deployment options
  • The variables: Things to consider as you prepare to deploy
  • The Microsoft Online Services Directory Synchronization tool
  • Mail routing
  • Migration methods and tools

Terminology: The secret decoder ring

As you explore the software and supporting documentation, you’ll see that we’ve used terms like “rich coexistence” and “simple coexistence”, and “cross-premises deployments” and “hybrid deployments.” These terms represent the evolution of the software to handle the basic “cross-premises” scenario.

We’re working to nail down the terminology. In the meantime, we hope this table helps you make sense of the terminology being used in the software and documentation.

Term

Description

hybrid deployment

The full-featured deployment of a cross-premises Exchange messaging solution with Office 365 for enterprises and Exchange Online. Features include:

  • Mail routing between on-premises and cloud-based organizations
  • Mail routing with a shared domain namespace. For example, both on-premises and cloud-based organizations use the @contoso.com SMTP domain.
  • A unified global address list, also called a “shared address book”
  • Free/busy and calendar sharing between on-premises and cloud-based organizations
  • Centralized control of mail flow. The on-premises organization can control mail flow for the on-premises and cloud-based organizations.
  • A single Outlook Web App URL for both the on-premises and cloud-based organizations
  • The ability to move existing on-premises mailboxes to the cloud-based organization
  • Centralized mailbox management using the on-premises Exchange Management Console (EMC)
  • Message tracking, MailTips, and multi-mailbox search between on-premises and cloud-based organizations

hybrid

A shortened form of “hybrid deployment”

cross-premises

A generic phrase that refers to any messaging deployment where mail routing spans an on-premises deployment and a cloud-based organization.

rich coexistence

See “hybrid deployment”. The term “rich coexistence” has been replaced by “hybrid deployment”.

simple coexistence

An obsolete term referring to cross-premises deployments where Exchange 2010 isn’t deployed in the on-premises environment. In our development, we’ve found that this term is overly broad and so we’ve decided not to carry it forward. You will see “simple coexistence” referenced in some documentation and user interface.

Exchange migration

The Exchange Online functionality that you can use to move mailboxes, or in the case of IMAP e-mail migration, the contents of users' mailboxes, from your on-premises Exchange organization to the cloud. You’ll find the Exchange Online migration tools on the E-Mail Migration tab in the Exchange Control Panel. There are three types of Exchange migration:

  • Cutover Exchange migration, referred to previously as simple Exchange migration.
  • Staged Exchange migration, which allows you to maintain mail routing across an on-premises deployment and a cloud-based organization for the short or long term
  • IMAP e-mail migration, used to migrate the contents of users' mailboxes from an IMAP messaging system to their cloud-based mailbox

single sign-on

The authentication process that lets your users use their existing Active Directory corporate credentials (user name and password) to access services in Office 365 for enterprises. Also called identity federation, single sign-on in Microsoft Office 365 uses Active Directory Federation Services 2.0 (AD FS).

identity federation

Also used to describe “single sign-on”, this term is used in Microsoft Office 365 documentation but will be phased out in favor of “single sign-on”. See the wiki post Federation in Office 365 and Exchange for an explanation of federation terminology used in Office 365.

hybrid server

A computer that is running a Hybrid edition of Exchange Server 2010 and is installed in an Exchange Server 2007 or Exchange Server 2003 organization for the purpose of enabling a hybrid deployment. This was previously referred to as a “coexistence server” in some documentation.

Return to top

Primary long-term e-mail deployment options

The Office 365 for enterprises planning and deployment tools have been designed to support either of the following long-term e-mail deployment options:

  • Hybrid deployment   Mailboxes for your organization can reside on-premises in an Exchange organization and in the cloud. In the hybrid deployment scenario, messaging functionality is seamless across the on-premises deployment and the cloud deployment. For the full list of supported features, see “Hybrid deployment” in the preceding table.
    This hybrid deployment scenario can also include single sign-on, which lets users use their existing Active Directory on-premises credentials to access all on-premises and cloud resources.
  • All mailboxes in the cloud   If your long-term goal doesn’t require messaging functionality that spans cross-premises, you should plan to move all your mailboxes to the cloud. It may take a week or maybe months to complete the migration, but it’s the best option if your long-term goal is to migrate all your mailboxes to the cloud.

As we explain in the next section, many of the migration and cross-premises tools that have been developed to support these two long-term mailbox options can be used to support other cross-premises scenarios. However, the planning and deployment tools built in to Office 365 for enterprises and Exchange Online have been designed to support moving all mailboxes to the cloud and to support a hybrid deployment.

Return to top

Additional deployment options

Using the tools described in this document, you can put together other solutions that may work for your organization, for the short term, during migration only, or for the long term. Let’s take a quick look at these options.

Manage on-premises users with Office 365 tools

An alternative form of migration is to move all mailboxes to the cloud, but to continue to manage users and resources from your existing Active Directory. After you set up single sign-on and install the Microsoft Online Services Directory Synchronization tool, users can use their Active Directory corporate credentials (user name and password) to access their new mailboxes in the cloud and their existing on-premises resources. If your organization is running Exchange 2003 or a later version, and you have fewer than 1,000 mailboxes, you can run cutover Exchange migration to move your mailboxes and then configure single-sign on. For more information, see Cutover Exchange Migration and Single-Sign On.

Or, if you’re currently running Exchange 2003 or Exchange 2007 on-premises, you can use staged Exchange migration to enable this scenario. For more information, see Plan for User Identity in a Staged Exchange Migration.

Provision users from your on-premises Active Directory into the cloud

If you don’t require single sign-on, deploying Active Directory synchronization only in the on-premises organization lets you provision users from your on-premises Active Directory into the cloud. This solution may work for organizations that maintain mail routing between a cloud-based organization and a non-Exchange on-premises messaging system, or organizations that simply prefer to source all users from their on-premises Active Directory. Organizations with many users should consider a custom solution to synchronize passwords from the on-premises organization to the cloud for this scenario.

Explore third-party solutions

If you aren’t running Exchange 2003 or later, or you are running a web-based messaging system or some other on-premises messaging system, you may need to work with a partner to figure out a solution that meets your needs using the tools discussed in this paper. For example, IMAP e-mail migration may suffice as a method to move mailbox data for your users, while a third-party solution may be the answer to migrating messaging-based workflow solutions to Exchange Online.

Return to top

The variables: Things to consider as you prepare to deploy

After you’ve decided on your long-term e-mail deployment option, you need to learn about the tools that you can use to move mailboxes to the cloud and to make the migration phase a better experience for your users and IT staff. You should also take routing, mail flow, and identity management into account when you plan for migration or a hybrid deployment.

  • Identity management
  • Microsoft Online Services Directory Synchronization tool
  • Mail routing
  • Migration methods and tools

Identity management

How do you want to manage the identities of the users in the cloud? You have two options:

  • Non-federated identity
  • Single sign-on (also known as identity federation)

Non-federated identity

With non-federated identity, all users with mailboxes in the cloud use Office 365-generated credentials to access their Office 365 resources. You can create new user accounts and passwords for Office 365 users in the Office 365 portal. Alternatively, you can use directory synchronization to automatically provision users from the on-premises Active Directory. Either way, ultimately, credentials are generated and managed by Office 365.

If you have an on-premises identity management system, users will have a set of credentials for their Office 365 resources and a set of credentials for their on-premises resources.

The advantage of a non-federated identity management solution is that there is less overhead in deploying and setting up your identity solution. For some small organizations or for organizations that are moving all user resources to the cloud in the near future, a non-federated identity management solution is ideal.

The disadvantage to a non-federated identity solution for organizations that still maintain user resources on-premises is that the user experience is fractured and requires more user education about credential management. Support may be costly if you expect users to manage two sets of credentials for accessing many different resources across two deployments.

For medium-sized or large organizations, long-term management and helpdesk costs will likely make a non-federated identity solution more expensive than single sign-on.

Single sign-on

When you deploy single sign-on, all users with mailboxes in the cloud use their existing on-premises Active Directory credentials to access both cloud and on-premises resources.

In a nutshell, you enable this by installing an AD FS server or servers in your on-premises organization. The AD FS server federates to the Office 365 service in the cloud to provide delegated access for your on-premises identities to specific Office 365 and Exchange Online resources in your cloud-based domain namespace.

The advantage of single sign-on is that users don’t need to learn a new credential management scheme. In addition to the user benefits, there are many benefits to administrators:

  • Policy control: The administrator can control account policies through Active Directory, which gives the administrator the ability to manage password policies, workstation restrictions, lock-out controls, and more, without having to perform additional tasks in the cloud.
  • Access control: The administrator can restrict access to Office 365 so that the services can be accessed through the corporate environment, through online servers, or both.
  • Reduced support calls: Forgotten passwords are a common source of support calls in all companies. If users have fewer passwords to remember, they are less likely to forget them.
  • Security: User identities and information are protected because all of the servers and services used in single sign-on are mastered and controlled on-premises.
  • Support for strong authentication: You can use strong authentication, also called two-factor authentication, with Office 365. However, if you use strong authentication, you must use single sign-on.

After you deploy AD FS and directory synchronization, you manage all users and resources from your existing on-premises Active Directory.

The disadvantage of single sign-on is that you have to install new servers, which require a certificate issued by a certification authority (CA) and add some complexity and cost to user management.

Note   Single sign-on is recommended, though not required, in the hybrid deployment scenario.

Single sign-on may also be a good solution for some large organizations that plan to migrate all mailboxes to Office 365 over many months.

Over time, for most organizations that plan to maintain an on-premises set of Active Directory resources along with Office 365, single sign-on is a good solution for streamlining user identity management.

Important

  • Single sign-on with AD FS requires Active Directory on-premises.
  • Single sign-on requires that you install and run the Microsoft Online Services Directory Synchronization tool.
  • If you plan to migrate all mailboxes to the cloud and set up single sign-on, you can’t deploy AD FS or directory synchronization before you run a cutover Exchange migration in the Exchange Control Panel. You can, however, run a staged Exchange migration after you deploy AD FS and directory synchronization.

For more information, see the following:

Return to top

The Microsoft Online Services Directory Synchronization tool

The Microsoft Online Services Directory Synchronization tool is primarily used to synchronize the Exchange global address list, also known as the shared address book, support complex routing scenarios, and provision users in a cross-premises deployment. Directory synchronization is a requirement for the hybrid deployment scenario, and it may produce a better user experience in some migration scenarios, especially if you plan to enable single sign-on.

However, from a user management perspective, directory synchronization is intended for long-term use. Although you can deactivate (and reactivate) directory synchronization, you should consider the deployment of directory synchronization as a long-term commitment. For more planning information about deactivating and reactivating directory synchronization, see the wiki post, Directory synchronization and source of authority.

By default, the Directory Synchronization tool synchronizes one-way from the on-premises directory to the cloud directory by writing user and mailbox information into the cloud directory for your Office 365 organization.

To enable some features of hybrid deployment, you must grant write access to the Directory Synchronization tool to synchronize some messaging-related user data back into the on-premises Active Directory. The following features are enabled by write access synchronization with your on-premises Active Directory:

  • Archiving on-premises mailboxes to the cloud
  • Moving mailboxes from the cloud to the on-premises Exchange organization
  • Synchronizing user-managed safe sender and blocked sender lists from the cloud
  • Synchronizing voice mail notifications from the cloud

Important   Directory synchronization is required for the following: hybrid deployment; single sign-on; and staged Exchange migration.

For more information, see Active Directory synchronization: Roadmap.

Return to top

Mail routing

Generally speaking, mail routing for a hybrid deployment is straightforward. The tools (mainly the Directory Synchronization tool) are optimized for pointing your MX record to your on-premises Exchange system as the authoritative domain. E-mail to cloud-based recipients is then relayed from the on-premises Exchange organization to the cloud. The Exchange Server Deployment Assistant explains how to configure this routing scheme for hybrid deployments.

You can also configure routing for hybrid deployments so that the MX record points to the cloud as the authoritative domain. For more information, see Hybrid Routing – Pointing your MX record to the Cloud.

More complex mail routing configurations typically come into play only if you are planning a long-term deployment where messaging systems span the on-premises and cloud deployments. In most cases, if you plan to migrate all your mailboxes to the cloud, you don’t need to consider complex mail routing scenarios. The exception here may occur for long, staged migrations where advanced mail routing might be required to maintain e-mail quality of service during the migration.

Important   Both cutover Exchange migration and staged Exchange migration manage short-term e-mail synchronization during the migration phase. Cutover Exchange migration synchronizes e-mail using subscriptions until migration is complete. Staged Exchange migration routes e-mail by stamping the cloud target address on the on-premises mailboxes.

Return to top

Migration methods and tools

The following migration methods and tools are available:

  • Move requests with the Mailbox Replication Service (MRS)
  • Cutover Exchange migration
  • Staged Exchange migration
  • IMAP e-mail migration
  • PST Capture
  • Third-party solutions

The Exchange Server Deployment Assistant explains how deploy most of these solutions.

Move requests with the Mailbox Replication Service (MRS)

The Microsoft Exchange Mailbox Replication Service (MRS), which resides on all Exchange 2010 Client Access servers, is the service responsible for mailbox moves, importing and exporting .pst files, and restoring disabled and soft-deleted mailboxes.

Move requests require a hybrid deployment. Move requests let you move mailboxes back and forth between your on-premises Exchange organization and the cloud. You do this in the Exchange Management Console.

If you plan to migrate and implement a long-term hybrid deployment with Exchange on-premises, move requests are the recommended way to migrate mailboxes.

Also, for large organizations that are running Exchange 2003 or Exchange 2007 on-premises and plan to move all mailboxes to the cloud over a period of several months, using move requests as a tool for a long, staged Exchange migration, which is essentially a hybrid deployment, may make sense.

Important   Move requests require a minimal installation of an Exchange 2010 hybrid server in your on-premises Exchange organization. You must be running Exchange 2003 or later to deploy the hybrid solution. The Exchange Server Deployment Assistant can help you generate a hybrid deployment plan.

For more information, see the following:

Cutover Exchange migration

Cutover Exchange migration is for organizations that have fewer than 1,000 mailboxes and want to move all mailboxes to the cloud in a single operation. Use E-Mail Migration in the Exchange Control Panel to access the tool.

Important

  • Cutover Exchange migration only supports Exchange 2003 or later. If you are running older versions of Exchange, you have to use IMAP e-mail migration or a third-party solution.
  • If you are running Exchange and have more than 1,000 mailboxes, consider using staged Exchange migration.
  • If you plan to deploy single sign-on, run cutover Exchange migration first, and then set up single sign-on (and directory synchronization after the migration is complete). Running directory synchronization before you run cutover Exchange migration will cause the migration to fail.

For more information, see the following Exchange Online topics:

Return to top

Staged Exchange migration

Staged Exchange migration is for larger organizations or organizations that want to migrate mailboxes to the cloud over time. In this scenario, you can migrate some mailboxes to the cloud while maintaining the rest of the mailboxes in your on-premises organization. Use E-Mail Migration in the Exchange Control Panel to access the tool.

Important

  • Staged Exchange migration has been designed for organizations that plan to move all on-premises Exchange mailboxes to the cloud eventually. It’s not a best practice to use staged Exchange migration to migrate a handful of mailboxes as part of a longer coexistence scenario.
  • Staged Exchange migration only supports Exchange 2003 or Exchange 2007. If you are running older versions of Exchange, you have to use IMAP e-mail migration or a third-party solution. If you are running Exchange 2010, you must implement a hybrid deployment and use move requests to migrate.
  • Staged Exchange migration requires directory synchronization.
  • If you plan to deploy single sign-on as part of your long-term deployment plan, set up single sign-on and directory synchronization before you run the staged Exchange migration.

For more information, see the following:

IMAP e-mail migration

IMAP e-mail migration is designed as a fallback e-mail content migration tool for a wide variety of e-mail servers. If you are running Exchange 2000 Server or Exchange Server 5.5 Service Pack 4, or any other compliant IMAP server, such as Gmail, IMAP e-mail migration is an option. Use E-mail Migration in the Exchange Control Panel and a CSV file.

For more information, see the following Exchange Online topics:

PST Capture

Another method for migrating mailbox items to cloud mailboxes is Microsoft Exchange PST Capture. PST Capture lets you search for and collect PST files on computers in your on-premises organization and then import the PST files to cloud mailboxes. Note that you can also use PST Capture to import PST files to on-premises primary or archive mailboxes. For more information, see Microsoft Exchange PST Capture.

Third-party solutions

Here are some third-party migration tools and partners that can assist with Exchange migrations from non-Microsoft platforms:

  • Binary Tree   Provider of cross-platform messaging migration and coexistence software with products that provide for the analysis of, and the coexistence and migration between, on-premise and online enterprise messaging and collaboration environments based on IBM Lotus Notes and Domino, and Microsoft Exchange and Microsoft SharePoint.
  • BitTitan  Provider of self-service e-mail migration and coexistence solutions to Exchange 2007 and Exchange Online.
  • Cemaphore   Provider of migration solutions from on-premises Microsoft Exchange to Microsoft Online.
  • Quest   Provider of migration solutions for Exchange Online and SharePoint Online, including migrations from Lotus Notes and Novell GroupWise to Exchange Online.
  • Metalogix   Provider of migration solutions to Exchange Online and SharePoint Online.

Return to top