Exchange Hybrid Deployment and Migration with Office 365

Exchange Hybrid Deployment and Migration with Office 365

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.

Why not try our 30 day trial free, after 30 days if it’s not for you, just stop using it!

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.

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.

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.
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.

We would love to hear your views on this...