Migrating Exchange Server to Office 365 - Metalogix · PDF file5 MIGRATING EXCHANGE SERVER TO OFFICE 365 WHITE PAPER At this point, you will have to click on the plus sign icon and

WHITE PAPER

Migrating Exchange Server to Office 365By: Brien M. Posey

2

Copyright © 2014 Metalogix International GmbH. All rights reserved. Metalogix is a trademark of Metalogix International GmbH. StoragePoint is a registered trademark of BlueThread Technologies, Inc. Microsoft, Exchange Server, Microsoft Office, SharePoint, and SQL Server are registered trademarks of Microsoft Corporation.

MIGRATING EXCHANGE SERVER TO OFFICE 365WHITE PAPER

CONTENTS

Domain Verification.................................................................................................................. 3

IMAP Migration........................................................................................................................... 4

Cut Over and Staged Migration Prep Work...................................................................... 5

Cut Over Migrations................................................................................................................. 6

Staged Migration....................................................................................................................... 7

Other Migration Tasks............................................................................................................ 10

Microsoft Migration Tools......................................................................................................11

Third Party Migration Tools...................................................................................................11

Conclusion..................................................................................................................................12

3

As organizations make the decision to transition from on premise Exchange Server deployments to Office 365, administrators are sometimes left wondering how to perform the migration. Microsoft supports several different migration types of migrations, but each migration path is intended for use in very specific situations. In addition, there are third party tools available that can either assist with or even automate the migration process. This whitepaper discusses the various migration options that are available, as well as the advantages and disadvantages of each approach.

Before you begin the migration to Office 365, you will typically need to add and verify your domain name. The reason for this is that in most cases you will want to keep the same domain name that you are using right now.

To add your domain name to Office 365, open the Office 365 Admin Center and click on Domains. When you arrive at the Domains screen, click the Add a Domain link. This will cause the Add a Domain to Office 365 Wizard to be launched. This wizard guides you through three steps.

The first step is the most important. This is where you specify your domain name and confirm that you own the domain name. The confirmation process is based around requiring you to add a special record to your DNS server. If Office 365 is able to confirm the existence of this record then it is assumed that you own the domain.

The second step is to add users and assign licenses. Although you can certainly do that, users can also be added in bulk as a part of the migration process.

The last step is to set the domain’s purpose. Your domain name can be used for Exchange and Lync or for SharePoint, but not for all three. Obviously, you would want to assign the domain name to Exchange and Lync. If you need to use the domain name for SharePoint too, then the workaround is to create a subdomain for SharePoint.

As you complete the Add a Domain to Office 365 Wizard, it is important to remember that you must not yet redirect the MX DNS record to Office 365. If you update the MX record right now you will break mail flow.

DOMAIN VERIFICATION


4


The most basic type of Office 365 migration that you can perform is an IMAP migration. This migration type is only appropriate for migrating users from an IMAP based mail system to Office 365. Unlike the other types of migrations that will be discussed, IMAP based migrations do not migrate non messaging data such as calendar entries or contacts.

Office 365 supports IMAP based migrations primarily as a mechanism for migrating messaging data from non-Microsoft mail systems. That being the case, there is quite a bit of manual prep work that must be performed prior to the actual migration.

Before you will be able to perform an IMAP migration, each user will need an Office 365 account and a corresponding mailbox. You can create accounts and mailboxes manually through the Office 365 Admin Center, but if you have more than a handful of mailboxes to migrate then it will likely be much easier to create and import a CSV file for mailbox creation than to create the mailboxes manually.

To use a CSV file, log into Office 365, and select Users and Groups, and click Bulk Add. When you do, you will see an option to download a blank CSV file. After downloading this file, open it in Microsoft Excel, and populate the file with data for the users that you want to import. The Select a CSV file screen that you used to download a blank CSV file also provides an option to import your CSV file. As a general best practice, you should test the import process with a few user accounts prior to attempting a large scale account import. Once you have finished the import process, hang onto the CSV file because you will need it again later.

Once you have created Office 365 accounts for your users, you will need to test external connectivity to your IMAP server. The easiest way to do this is to open the Microsoft Remote Connectivity Analyzer (https://testconnectivity.microsoft.com/) and choose the IMAP Email option. Upon doing so, you will be prompted to enter the fully qualified domain name (FQDN) of your IMAP server, as well as a few other pertinent details. The Remote Connectivity Analyzer will then verify that it is possible to connect to your IMAP server from the outside world. If this test fails then you may need to open firewall ports 143 (standard IMAP connectivity) and 993 (SSL connectivity).

Another thing that you should do before continuing on is to make a decision as to which folders you wish to migrate to Office 365. It is common to skip synchronizing the Deleted Items and the Junk Mail folders.

In the unlikely event that your IMAP server is Exchange based, then it is extremely important that you initially exclude public folders from the migration process. Otherwise, every mailbox will receive a full copy of each public folder.

When the prep work is done, you can begin the migration process. To do so, log into Office 365 with administrative credentials and then open the Exchange Admin Center. With the Recipients tab selected, click on the Migration option.

IMAP MIGRATION

5


At this point, you will have to click on the plus sign icon and then choose the Migrate to Exchange Online option from the drop down menu. The following screen will prompt you to choose your migration type. Choose the IMAP Migration option.

Click Next and you will be prompted to import the CSV file that you created earlier. After doing so, click Next and you will see a screen asking you to provide a name for the migration batch. You can call the migration batch anything that you want, but it is a good idea to make the name descriptive.

Next, click Add Folders to Exclude. This is where you are able to specify the folders that you want to omit from the migration. Be sure to spell the folder names exactly as they are spelled on your IMAP serer.

Click Next and Exchange will verify that your CSV file is formatted correctly and that it is of the appropriate size. The CSV file must be less than 10 MB in size and contain less than 50,000 rows.

Assuming that the CSV verification checks are successful, you will be taken to the Migration Batch Created Successfully page. You can launch the migration process by clicking Start.

CUT OVER AND STAGED MIGRATION PREP WORK

If you are currently running Exchange Server on premises then you will want to perform either a cut over migration or a staged migration. Cut over migrations are more appropriate for smaller organizations, while staged migrations are intended for larger organizations. In either case, there are some tasks that you will have to perform in order to prepare for the migration process.

Before you will be able to perform a cut over or a staged migration, your existing Exchange Server organization must be configured to support Outlook Anywhere (or RPC over HTTP as it used to be called). The easiest way to verify that your existing Exchange Server organization is configured correctly (from a connectivity standpoint) is to use the Remote Connectivity Analyzer (https://testconnectivity.microsoft.com/) to test Outlook Anywhere functionality.

Using the Remote Connectivity Analyzer requires you to enter some basic information such as an E-mail address, domain \ username, and a password. If your existing Exchange Server deployment is running Exchange Server 2007 or 2010 then you can also use this connectivity test to verify that the Autodiscover service is working correctly. However, the Autodiscover service did not exist prior to Exchange Server 2007, so if you are currently running Exchange Server 2003 you will have to manually specify your server name, your RPC proxy server, and your mutual authentication principle name.

VERIFY CONNECTIVITY

6


CUT OVER MIGRATIONS

Cut over migrations have been described as the most quick and dirty type of migration that can be performed. As the name implies, a cut over migration involves an abrupt switch from one system to another. Cut over migrations are the least complicated migration type that ultimately results in all Exchange Server data being migrated to Office 365.

The primary disadvantage to performing a cut over migration is that cut over migrations are not appropriate for every environment. This migration type is only a viable option for small to medium sized organizations with up to 1000 mailboxes. Cut over migrations are supported for Exchange Server 2003, 2007, and 2010.

Once you have confirmed that Outlook Anywhere connectivity is working correctly, it is time to perform the actual migration. To do so, log into Office 365 with administrative credentials and then open the Exchange Admin Center. With the Recipients tab selected, click on the Migration option.

At this point, you will have to click on the plus sign icon and then choose the Migrate to Exchange Online option from the drop down menu. The following screen will prompt you to choose your migration type. Choose the Cut Over Migration option and then click Next.

The next screen that you will see prompts you to enter the E-mail address of one of the mailboxes that is to be migrated. This same screen also requires you to enter a set of administrative credentials.

Click Next and you will be taken to the New Migration Batch screen. Depending on the version of Exchange that you are currently running and depending on how Exchange is configured, you might see a warning message telling you that you must manually enter your server name. If you see such a warning, go ahead and specify the name of your mailbox server. You might also have to manually specify your RPC proxy server name.

Click Next and enter a name for the migration batch. The name that you enter should be something descriptive, such as Exchange 2007 to Office 365. Click Next to continue.

The next screen that you will encounter asks you to pick an existing Office 365 user who will receive a report when the migration completes. This screen also asks you if you want to automatically start the batch, or if you would prefer to manually start the batch later on.

After making your selection, click the New button. The migration batch will be created. If you chose to automatically start the batch then the batch’s status will indicate Syncing. The mailboxes will now be migrated.

Although a cut over migration migrates mailboxes to Office 365, it does nothing to redirect inbound mail. After the migration process completes, you will have to change your DNS server’s MX record to point to Office 365. Due to the hierarchical nature of the DNS infrastructure and DNS caching, it can take a while before messages are being consistently delivered to Office 365. That being the case, Microsoft recommends that you keep your migration batch job running for a full three days after the change to the MX record is complete.

7


Staged migrations are different from the other two migration types that have been discussed so far, in that a staged migration is not designed to migrate all of your mailboxes at once. A staged migration allows you to migrate a subset of your Exchange Server mailboxes to Office 365. You can do so as a way of gradually making the transition to Office 365, or you can use a staged migration as a way of freeing up capacity on your on premise mailbox servers.

It is worth noting that staged migrations are not suitable for Exchange Server 2010 deployments. Microsoft recommends using cut over migrations for Exchange 2010 deployments with fewer than 1000 mailboxes or using hybrid migrations for larger Exchange 2010 deployments.

Another thing that makes staged migrations different from the other types of migrations that have been discussed is that you will have to establish a synchronization between your on premise Active Directory environment and the Office 365 directory. In order to do so, you will need to set up two machines (preferably virtual machines). You will need an AD FS Server, and a Directory Sync Server. If you need to authenticate requests from external clients then you will also need an AD FS proxy server, but the proxy server is beyond the scope of this paper. This whitepaper will assume that all of these servers are running on Windows Server 2012.

Performing a staged migration requires you to create a CSV file that will act as a list of the users that you want to migrate. This CSV file must adhere to a very specific format. You can find the specifics for building this file at: http://help.outlook.com/en-Us/140/ff959691.aspx

One thing that you may have to do is to add a UPN suffix to your Active Directory objects. Suppose for instance that you currently use contoso.local as a domain name, but you want to use contoso.com for your cloud domain name. You would need to add a UPN suffix to accommodate the desired domain name.

You can add the UPN suffix through the Active Directory Domains and Trusts tool. Open the console and then right click on the Active Directory Domains and Trusts container and select the properties command from the shortcut menu. Select the Suffix tab within the resulting dialog box and add your UPN suffix.

PREPARING A CSV FILE

ADDING A UPN SUFFIX

STAGED MIGRATION

8


To prepare the AD FS server, you will need to domain join your AD FS server, create a service account, and then use Server Manager to deploy the Active Directory Federation Service role. The service account should be a tenant account on Office 365 and it does not need to have a license assigned. You must assign the account the Global Administrator role.

The next thing that you will have to do is to install the Sign In Assistant. To do so, log into Office 365 and open the Office 365 Admin Center. Click on the Download Software link and click Desktop Setup, Setup, Run. This will cause the Desktop Assistant to be downloaded.

When you run the Desktop Assistant, you will be prompted to log in using your service account. The utility will now prepare to install various desktop applications. Deselect the option to install Outlook, SharePoint and Lync and then click Continue. Follow the prompts to complete the installation of the Sign In Assistant.

The other thing that you will have to install is the Windows Azure Active Directory Module for PowerShell. Open the Office 365 Admin Center and click on Users and Groups. Now, click on the Set Up link for Single Sign On. When prompted, download the Windows 64-bit version. When the download completes, run the file that you downloaded and follow the prompts to install the Windows Azure Active Directory Module for PowerShell.

When you installed the AD FS role, IIS was installed as a part of that role. You will need to assign a certificate to the IIS server so that it can use SSL encryption. The actual method that you will have to use to request a certificate and bind it to your Web server will vary depending on where you are getting the certificate from. Microsoft provides a walkthrough of acquiring a certificate from an enterprise certificate authority at: http://office365support.ca/part-2-request-fulfill-complete-and-assign-a-third-party-certificate/

The next part of the process involves configuring the Active Directory Federation Service. To do so, open Server Manager and then choose the AD FS Management command from the Tools menu. When the console opens, click AD FS Federation Server Configuration Wizard, and then choose the option to create a new federation service. As you work through the prompts, you must tell Windows that you want to create a new federation server farm and you will have to assign a name to the Federation Service. The name that you assign must match the certificate name. The wizard will also prompt you to enter the name of your service account.

Now you must establish a federated trust between your Active Directory and Office 365. Run the Azure Active Directory Module for PowerShell with Administrator credentials. When PowerShell opens, enter the following command:

$Cred=Get-Credential

You will now see a login prompt. Enter the credentials for the service account that you created earlier. Now, enter the following commands:

SETTING UP AN AD FS SERVER


9

Connect-MsolService –Credential $cred

Set-MsolADFSContext –Computer <the fully qualified domain name of your AD FS server>

Convert-MsolDomainToFederated –DomainName <your domain name>

The directory synchronization server is a 64-bit server running a SQL Server database that establishes a one way synchronization between your Active Directory forest and Office 365. The directory sync software includes a copy of SQL Server Express, but you can use a dedicated SQL server to accommodate larger directories. As a best practice, you should run the directory synchronization software on a dedicated machine (physical or virtual).

The first thing that you will need to do is to activate directory synchronization by opening the Office 365 Admin Center and then clicking on Users and Groups and using the Activate link to activate Directory Synchronization.

Next, you will have to download and install the Directory Sync software. You can get the software by clicking the Set Up link (which is located near the Set Up link that you used in the previous step. After downloading the software, you will have to work through a very simple installation wizard.

Once the Directory Synchronization software is up and running, you will have to configure directory synchronization. To do so, open the Directory Sync Configuration Wizard and then click Next to bypass the wizard’s Welcome screen. You will now be prompted to provide a set of credentials. Specify the service account that you just created, and click Next.

You will now be prompted to enter a set of Active Directory credentials. Enter the credentials for an account with Active Directory Enterprise Admin credentials in your local forest. It is extremely important that the password for this account and for your Office 365 service account be set to never expire.

Click Next and then you will see a screen asking if you want to enable a hybrid deployment. Select the Enable Exchange Hybrid Deployment check box and then click Next. The configuration process will begin. When the process completes, click Next.

When you see the wizard’s final screen, select the Synchronize Directories Now check box and click Finish.

Now that the prep work is done, you can perform the staged migration. Staged migrations are performed in batches. Begin the process by opening the Exchange Admin Center and then clicking on the Migration link. Next, click on the plus sign icon and then choose the Migrate to Exchange Online option from the drop down menu. The following screen will display a list of the various types of migrations that you can perform. Choose the Staged migration option and click Next.

SETTING UP A DIRECTORY SYNCHRONIZATION SERVER

WORKING THROUGH A STAGED MIGRATION

10


Click Next and you will be prompted to provide a CSV file containing the users that you wish to migrate. Use the Browse button and then supply the CSV file that you created earlier.

Once you have provided the CSV file, click Next and you will be prompted to provide a name for the batch of mailboxes that you want to migrate. You should use a descriptive name such as Marketing Department or Seattle Office. This screen also gives you the opportunity to send a copy of the migration report to someone in your office.

When you are done creating the batch click Next. Assuming that everything is set up correctly, you should see a message stating that the migration batch was created successfully. Review any information that is displayed and click Close. You can migrate the batch by selecting the batch and clicking Start.

When the process completes, Microsoft strongly recommends that you convert on premise mailboxes to mail enabled users. This will cause the Autodiscover service to configure Outlook to connect to the cloud based mailbox.

Regardless of which method you use to perform the migration, there are a number of migration tasks that will have to be completed outside of the New Migration Batch wizard. One such task is to migrate any existing public folders. Public folders are not migrated as a part of the mailbox migration process.

Another thing that you will have to do is to configure Outlook to connect to Office 365. Ideally, the Autodiscover service should pick up on the new mailbox location, but there are circumstances in which Outlook requires manual intervention.

Depending upon the type of migration that you have performed, you may have to assign an Office 365 license to each user. Licenses can be assigned through the Office 365 Admin Center. To do so, click on Users and Groups and then click on a user’s display name. You can use the checkboxes on the resulting screen to assign or remove licenses.

One last migration task that you will need to complete is stopping the migration batch from running. The migration batch should run until all mailboxes in the batch have been migrated and mail is consistently flowing to the Office 365 mailboxes. You can delete a migration batch after it is stopped.

OTHER MIGRATION TASKS


As you can see, there are a number of different criteria that must be considered when choosing the most appropriate migration method for your organization. Thankfully, Microsoft offers a free tool that can help you to determine which migration method you should be using. The tool is called the Exchange Server Deployment Assistant (http://technet.microsoft.com/en-US/exdeploy2013/Checklist?state=2284-W-AAAAAAAAQAAAAAEAAAAAAA%7e%7e).

The Exchange Server Deployment Assistant is an online tool that is designed to help you with the migration process. The tool asks you a series of questions about your on premise Exchange Server deployment and about your goals for the migration. Once you have answered the necessary questions, the tool provides recommendations and instructions for the migration.

MICROSOFT MIGRATION TOOLS

Although Microsoft provides all of the necessary tools for working through the various migration scenarios, there is a lot of work involved in planning, configuring, and performing the migration. Because there is so much work involved, there is a lot of room for error. Administrators often find Office 365 migrations to be a very frustrating experience.

One way to make the migration process easier is to make use of third party migration tools rather than relying solely on native tools. One particularly useful third party tool is Email Migrator from Metalogix. There are a number of benefits to using Email Migrator.

Email Migrator greatly simplifies the process of working through staged migrations. The entire migration process can be managed through a single interface. The tool is also able to perform all of the required pre-migration analysis required to ensure that the migration goes smoothly.

A simplified interface alone might not be a sufficient reason for investing in a third party tool. The primary benefit to using Email Migrator is that it handles migration related tasks that are well beyond the scope of those described earlier in this whitepaper.

The techniques that were previously discussed are used for migrating mailboxes from an on premise Exchange Server to Office 365. Although the mailbox contents are migrated, there are a number of things that administrators must be on the lookout for. For example, mailbox rules and other compliance related settings are easily lost in the migration process. Email Migrator ensures compliance by retaining any existing rules. Because the software maintains a true hybrid Exchange Server deployment, it is also possible to perform search and discovery across the on premise and the Office 365 environments.

Although there are costs involved in investing in a third party migration tool, administrators must also consider the cost of performing migrations manually. The complexity of the manual migration process typically results in a considerable number of man hours being spent preparing for, working through, troubleshooting, and cleaning up after the migration. A third party tool that greatly simplifies the migration process can greatly reduce the amount of time required for completing a migration, while also reducing the changes that down time will result from a configuration error.

THIRD PARTY MIGRATION TOOLS

11

12

Metalogix is the leader in management software for Microsoft content and collaboration platforms, including SharePoint, Exchange, and Office 365. Metalogix software solutions provide a better way to monitor, migrate, store, synchronize, archive, govern and backup content.

14,000 customers on 7 continents rely on Metalogix’ best of breed products and 24x7 LIVE support to improve availability, reduce risks, and lower costs of their mission-critical Microsoft platforms.

Metalogix is a Microsoft Gold Partner, Microsoft Public Sector managed partner and certified GSA provider. Headquartered in Washington DC, Metalogix is backed by Insight Venture Partners and Bessemer Venture Partners.

ABOUT METALOGIX

METALOGIX5335 Wisconsin Ave NW, Suite 510, Washington DC 20015

[email protected] | www.metalogix.com | 1.202.609.9100


Although Microsoft tries to make Office 365 migrations sound easy, the reality is that they are usually anything but. There is a vast amount of planning and configuration that must take place before the migration process even begins. Once the migration completes, administrators must take the time to make sure that all of the appropriate settings are still in effect. Although the techniques described in this paper are meant to serve as an overview of the migration process, it is extremely important to consult Microsoft’s documentation prior to attempting an Office 365 migration. It is also highly recommended to use a third party migration tool such as Email Migrator from Metalogix to assist with the migration process.

CONCLUSION

Documents

Migrating Exchange Server to Office 365 - Metalogix · PDF file5 MIGRATING EXCHANGE SERVER TO OFFICE 365 WHITE PAPER At this point, you will have to click on the plus sign icon and