IT shops require a clear remediation plan to migrate to Office 365 services. The preparations will vary based on the chosen migration approach: hybrid, third-party, staged, IMAP or cutover.
Before enabling Office 365 services, numerous areas typically require remediation:
- Patch the Exchange environment
- Update User Principal Names in Active Directory
- Implement corrections the Microsoft IDFix tool recommends
- Replace or obtain additional Secure Sockets Layer (SSL) certificates
- Update Proxy Server exclusions
- Modify firewall rules
- Acquire and implement bandwidth upgrades
- Correct DNS entries and patch Office clients
The assessment should provide a list of accepted domains that must be registered within Office 365. Start by verifying the domains and adding them to Office 365. At this stage, no MX records are likely to be switched.
If you plan to use the cutover migration approach, you'll use a CSV file to create an import file instead of relying on directory sync tools. After the cutover migration, you could choose to implement the identity management tool set.
Other migrations typically require a little more preparation, although third-party tools make this optional. Identity management implementation usually starts with a Windows Azure AD Sync Tool (DirSync) install or, for multi-forest environments, Azure AD Sync Services. These copy and link end-user accounts from AD to Azure AD in Office 365, and may also copy the hash of passwords. DirSync with Password Hash Sync meets requirements for many organizations and is a simple installation that allows the sign-on with the same password as used with AD.
Office 365 services implementation
For organizations requiring true single sign-on or integration with on-premises multifactor authentication systems, Active Directory Federation Services (AD FS), a component of Windows 2012 R2, is used in conjunction with Windows 2012 Web Application Proxy in the DMZ. AD FS can then be federated with Office 365, meaning all password requests redirect to on-premises AD FS servers.
When migrating email, the implementation steps depend on the specific migration approach.
A hybrid environment will need either an Exchange 2010 Client Access and Hub Transport server or an Exchange 2013 Client Access and Mailbox server if neither is currently installed on an Internet-facing site. This means enabling hybrid for Exchange 2010/Exchange 2013 is simple, but enabling hybrid for older organizations is similar to the first steps of an Exchange migration. Assuming prerequisites such as firewall rules have been configured, the Hybrid Configuration wizard implements all necessary connectors required for mail flow, mailbox moves and sharing.
A staged or cutover migration requires Outlook Anywhere to be configured and enabled externally, along with valid SSL certificates. An IMAP or staged migration also requires mail routing to be configured. This allows the accepted domains to be shared between on-premises servers and Office 365. At a minimum, an outbound connector is required in Office 365 to route email for the shared domain to the on-premises deployment.
Third-party tools differ, but most use either Outlook Anywhere or Exchange Web Services. Prerequisite configuration is similar to a staged migration when routing mail for coexistence is configured, but each tool has a different approach when performing the configuration. As an example, BitTitan MigrationWiz works best with a service account in the source and the target that can use impersonation to access mailboxes. A connector is created with credentials specified for both environments, and then accounts to migrate are added.
Enabling Office 365 services
After you've configured base services and have performed associated basic testing, other required Office 365 services should be enabled. Office 365 Multifactor SKUs such as E3 provide authentication and ensure that a physical device and password are required. Office 365 Mobile Device Management (MDM), which is based on Microsoft Intune, is also worth considering. Office 365 MDM monitors email profiles and Office 365 applications on mobile devices.
The actual transition to Office 365, after thorough testing, should be straightforward. After basic testing, conduct a technical pilot with end users, typically from the IT and Office 365 project team. Identify and correct any obvious issues at this stage. In conjunction with wider communications planning, identify the pilot group and orchestrate a dry run of real migrations that include real-world end users.
A successful pilot should then lead the creation of schedules and associated migration batches for the transition of end users to Office 365 services. The project team should clearly communicate this schedule and also take into account the available resources to assist end users with any necessary deskside reconfiguration. The migration often starts with smaller batches, but as confidence grows, so will the pace of migration. Be prepared to think on your feet through the migration and have the confidence to push forward when necessary, but also halt to deal with issues. Some, such as sharing problems when end users are split between the cloud and on-premises, are best dealt with by moving the on-premises users to Office 365.
About the author:
Steve Goodman is an Exchange MVP and is the head of unified communications at the U.K.'s leading Office 365 partner. Steve has worked in the IT industry for 16 years and has worked extensively with Microsoft Exchange since version 5.5. Steve is the author of a number of books about Exchange, regularly presents at conferences, co-hosts The UC Architects podcast and regularly blogs about Exchange Server, Office 365 and PowerShell at www.stevieg.org.
Staged vs. cutover migrations to Office 365
Pick an Office 365 migration method
IT pros concerned about Office 365 migration services