This chapter from Microsoft Office 365 Administration Inside Out discusses mailbox migration options and administering the different messaging workloads.

Mailbox migration options

Moving mailboxes back to on-premises Exchange

Decommissioning on-premises Exchange

Administering Exchange Online

Compliance, Legal Hold, and eDiscovery concepts

IN Chapter 10, we covered the different models of deploying Exchange Online, and in Chapter 11, we implemented an Exchange Online hybrid environment. We also performed tests to confirm key mailbox operations.

Now that you have incorporated Exchange Online in your environment, it is time to discuss mailbox migration options and administering the different messaging workloads. As we mentioned before, this book is about Office 365, so we will focus only on Exchange Online and hybrid administration topics in this chapter.

Mailbox migration options

There are three primary types of migration options:

Cutover migration

Staged migration

Hybrid deployment migration

A cutover migration is a process where all on-premises mailboxes and contents are migrated as a single batch and is applicable to Exchange 2003, 2007, 2010, and 2013 with fewer than 1,000 mailboxes. You must disable directory synchronization if you would like to do a cutover migration.

A staged migration is a process where a subset of mailboxes and content is migrated in several batches over time and is applicable only to Exchange 2003 and 2007. A staged migration is typically the approach if you have more than 1,000 mailboxes. A special consideration for staged migration is that you need to identify mailboxes that must be in the same migration batch. The mailboxes of individuals participating in delegate permissions must be kept together. Therefore, they need to belong to the same batch when you plan a staged migration.

If your organization has Exchange 2010 or 2013 with more than 1,000 mailboxes, you will need to implement an Exchange hybrid deployment, which is what you implemented in Chapter 11.

Cutover migration

A cutover migration is ideal for organizations with 1,000 mailboxes or less. The other important requirement for a cutover migration is that directory synchronization has not been established. The reason for this is because the cutover migration will create users in Office 365 as part of the process. Therefore, if directory synchronization is already synchronizing Active Directory (AD) objects to Office 365, you need to use a staged migration or migrate using a hybrid deployment.

A cutover migration is initiated through the Exchange admin center (EAC) for the latest release of Office 365. For organizations that are currently on Office 365 but have not been upgraded to the latest release, this is done through the Exchange Control Panel (ECP). You can also use Windows PowerShell to provision new Exchange Online mailboxes, and then migrate mailbox data from your on-premises Exchange to Exchange Online.

Before we look at how a cutover migration is set up, it is useful for you to know what happens when you execute a cutover migration. When a cutover migration is initiated, the following processes occur:

The migration service provisions new mailboxes in Exchange Online by reading the on-premises Exchange 2003 or 2007 address book.

On-premises distribution groups and contacts are migrated to Exchange Online.

The migration service then migrates the contents, contacts, and calendar items from on-premises mailboxes to their corresponding online mailboxes. This part of the process is called initial synchronization.

On-premises mailbox contents are synchronized with their corresponding online mailboxes every 24 hours. This part of the process is called incremental synchronization.

When you are ready to complete the migration, change the MX record to start routing emails to the online mailboxes and end the migration. Exchange will conduct a final synchronization and notify the administrator through email that the migration is complete. The email notification will contain two reports:

MigrationErrors.csv This report contains a list of mailboxes that failed to migrate and information about the error.

MigrationStatistics.csv This report contains a list of mailboxes and the corresponding number of items migrated. The report also includes a unique password assigned to each mailbox that the user will need to change after initial log on. Remember that this is because the cutover migration creates new accounts as part of the migration process.

You have the option to use Autodiscover or manually configure connection settings prior to initiating the cutover migration. Configuring Autodiscover was covered in Chapter 11.

Cutover migration with the ECP

Follow these steps to execute a cutover migration using the ECP:

Log on to Outlook Web App (OWA).

On the Options menu located at the upper-right corner of the OWA window, select See All Options, as shown in Figure 12-2.

Figure 12-2 Options menu in OWA.

Select the Manage Myself option, and then select My Organization, as shown in Figure 12-3. This will take you to the ECP.

The main pane shows migration processes and their corresponding statuses and errors. If there are any existing migration processes, you will see them listed here and you can edit, start, resume, pause, or delete the processes by using the controls on this page. To create a new cutover migration, click New.

Select whether to use Autodiscover, manually configure connection settings, or use IMAP for mailbox content migration, and then click Next.

Provide an administrator’s email address, log on with a credential and password, and enter the number of mailboxes to migrate simultaneously. The default is to migrate three mailboxes simultaneously, and the maximum is 50. Click Next.

ECP will test the connection to your on-premises Exchange server with the Autodiscover or manual connection settings. When the connection is successful, you will be prompted to provide a name for the batch migration.

Provide email addresses that the migration report should be sent to by typing in the addresses or by using the Browse button to select from the global address list.

Cutover migration with EAC

If your organization is using the latest release of Office 365, the ECP will not be an available graphical user interface (GUI) option. Instead, you will use the EAC. To initiate a cutover migration using the EAC, follow these steps:

Choose to either manually or automatically start the migration and provide email addresses that a report should be sent to after the migration is complete, as shown in Figure 12-10, and then click new.

Staged migration

A staged migration is initiated through the EAC, the ECP, or through Windows PowerShell. It is similar to a cutover migration except that you have the ability to identify a subset of mailboxes to migrate through a .csv file. Staged migration is the appropriate migration method if directory synchronization is already implemented.

Before we examine how to set up a staged migration, it is useful for you to know what happens during a staged migration. When you initiate a staged migration, the following processes occur:

The migration service checks that directory synchronization is configured, prompts for the .csv file, and checks that each entry in the .csv file is a mail-enabled user (MEU) in Office 365.

The service then converts the MEUs into mailboxes and populates the TargetAddress property of the on-premises mailbox with the email address of the cloud mailbox.

After the TargetAddress property has been updated for all mailboxes, you will receive an email with a list of mailboxes that have been successfully created and converted. Mailbox contents are not migrated yet, but the users can start using the mailbox without any MX record changes. This is because if emails arrive at the on-premises mailbox, they will be redirected to Exchange Online because of the TargetAddress property.

The migration service then starts to migrate the contents, contacts, and calendar items from the on-premises mailboxes to their corresponding online mailboxes. When content migration is done, another report is emailed to administrators.

At this point, you can create and start additional migration batches.

When you are done with migration, change the MX records so that email will be directly delivered to the online mailboxes. You can then complete the migration. The migration service will carry out any necessary cleanup and checks to make sure every MEU that has a corresponding on-premises mailbox has been migrated. A final status report will then be sent to the administrator.

Creating a .csv file

The first order of business to carry out a staged migration is to create a .csv file containing the attributes of mailboxes you want to migrate. The first row of the .csv file is the header row and should contain only the following attribute names:

EmailAddress This is the SMTP address of the mailbox and is the only required attribute.

Password The password that will be set for the cloud-based mailbox after it is migrated. This is an optional attribute and is not required if single sign-on (SSO) is enabled. If you set the password in the .csv file and SSO is enabled, it will be ignored. Simply leave this box blank if it does not apply to your configuration.

ForceChangePassword This Boolean attribute specifies whether the user must change the password when first logging on to the cloud mailbox. The value is either True or False. This is also an optional attribute and is not required if SSO is enabled. If you set this attribute in the .csv file and SSO is enabled, it will be ignored. Simply leave this box blank if it does not apply to your configuration.

Figure 12-11 shows an example of a .csv file for a staged migration. This .csv file will cause the staged migration process to migrate five mailboxes, set the password for the new cloud mailboxes to NewPa$$word, and require only Anna and Scott to change their password upon initial logon to their respective cloud mailboxes.

Provide an administrator’s email address, log-on credential, password, and the number of mailboxes to migrate simultaneously. The default is to migrate three mailboxes simultaneously, and the maximum is 50.

When prompted for the .csv file, click the Browse button to navigate to the location and file, and then provide a name for this staged migration batch, as shown in Figure 12-12. Note that by default, a report will be sent to the administrator’s email address identified in Step 7. You can provide additional email addresses if you want to have the report directed to other administrators in addition to the administrator identified in Step 7. The batch name cannot contain spaces or special characters. Click Next.

The migration wizard will verify the .csv file and contents to make sure there are no errors before creating the migration batch. If there are validation errors, you will see a warning such as the one shown in Figure 12-13. Click the Show error details link to get detailed information about the errors. The errors could be invalid email addresses or formatting errors in the .csv file. In this particular case, we had an email address in the .csv file that was not properly formatted.

After you have started the migration, you can monitor the process by selecting the batch migration and looking at the statistics located in the right pane, as shown in Figure 12-14. The status of the migration, number of mailboxes migrated, and errors are also listed along with the migration batch.

Staged migration with EAC

Starting a staged migration from the EAC is similar to a cutover migration from the EAC. Follow these steps to initiate a staged migration from the EAC:

Click the Browse button, navigate to the location of the .csv file, and select it. The wizard will read the .csv file, determine the number of mailboxes to be migrated, and display that information, as shown in Figure 12-16. Click next.

Figure 12-16 Selecting the .csv file in the EAC migration wizard.

Provide account credentials of an account that has access to the on-premises mailboxes that need to be migrated. The account is in the down-level format (domain\user name), as shown in Figure 12-17. Do not use the user principal name (UPN) as the account name. Click next.

Figure 12-17 Provide credentials of an account with permissions to on-premises mailboxes.

The migration wizard will try to automatically detect settings. If it is not able to do so, you will need to manually provide your on-premises server settings, as shown in Figure 12-18. Enter the information, if requested, and click next.

IMAP migration

An IMAP migration is commonly used in migrations from non-Exchange email systems to Exchange Online. As the name implies, the on-premises email system will need to have the IMAP protocol enabled to use an IMAP migration method. Prior to initiating an IMAP migration, there are two manual tasks you must perform:

Create a .csv file with the email address, user name, and password for each mailbox you will be migrating.

Like cutover and staged migrations, you will use either the ECP or EAC GUI to initiate an IMAP batch migration. You can also use Windows PowerShell to initiate an IMAP batch migration.

Creating a .csv file

Create a .csv file to target the on-premises users’ mailboxes whose content you want to migrate to Exchange Online. The first row of the .csv file is the header row and should contain only the following attribute names:

EmailAddress This is the user ID for the user’s cloud-based mailbox in UPN format. Note that this is not the SMTP address; this is the user ID in Office 365.

UserName This is the user logon name for the on-premises mailbox on the IMAP server.

Password This is the password for the user’s account on the on-premises IMAP mailbox server.

The .csv file for an IMAP migration batch must not be larger than 10 MB and cannot contain more than 50,000 rows. Furthermore, all three attributes are required. Contacts, calendar items, and tasks cannot be migrated with the IMAP method.

IMAP migration with the ECP

Follow these steps if your organization has not been upgraded to the latest release of Office 365 and would like to use the ECP to initiate an IMAP migration. This section assumes you have created mailboxes in Exchange Online for the on-premises users for whom you want to migrate content.

Log on to OWA.

From the Options menu located at the upper-right corner of the OWA window, select See All Options, as shown in Figure 12-2.

Select the Manage Myself option at the upper left, and select My Organization, as shown in Figure 12-3. This will take you to the ECP.

In the ECP, as shown in Figure 12-4, select E-Mail Migration under Users & Groups.

To create a new IMAP migration, click New, then select IMAP.

As shown in Figure 12-22, provide the fully qualified domain name (FQDN) of the on-premises email server in the IMAP server box. Select the authentication type, encryption level, and the IMAP port if it is not the standard port 993 for IMAP. Finally, specify the number of mailboxes to simultaneously migrate. Click Next.

The migration wizard will test the connection settings by attempting to connect to the on-premises mail server with the IMAP protocol. If successful, it will prompt you for the .csv file.

Click the Browse button to navigate to the location and .csv file. Provide a name for the IMAP migration in the Batch name box. Batch names cannot have spaces or special characters.

Click Add folders to exclude if you do not want to migrate the contents of certain folders, such as contents in the Deleted Items folder.

Type the name of the folder and click the Add button to add the folder to the exclusion list. Make sure you type the name of the folder exactly as it appears. Repeat this step until all the folders you want to exclude are added to the list. Click OK.

To send copies of the migration report to other administrators, click Browse at the bottom of the page and add other administrators. Click Next.

Exchange Online will check the .csv file to ensure that no errors are detected. If there are no errors, you will be notified that the .csv file successfully passed the checks.

Review the information about the migration batch, and then click Close.

The IMAP migration batch should now appear in the list in the ECP E-Mail Migration window. Select it, and then click Start to initiate the migration.

After the migration is completed, change your MX records so that new mail will be delivered to the cloud mailboxes.

IMAP migration with the EAC

If your organization is using the latest release of Office 365 and would like to use the EAC, follow these steps to initiate an IMAP migration:

After authentication, click the Admin menu on the upper-right corner of the page and select Exchange, as shown in Figure 12-5.

In the EAC, under recipients, select the migration tab from the main pane, as shown in Figure 12-6.

Select Migrate to Exchange Online. You will be provided with migration options, one of which is IMAP migration. Select it, and then click next.

Click the Browse button and navigate to the location and the .csv file. Click Open, and then click next.

Exchange Online will check the .csv file to ensure that no errors are detected. If there are no errors, you will see the number of mailboxes detected in the .csv file. Click next to continue.

As shown in Figure 12-23, provide the FQDN of the on-premises email server in the IMAP server box. Select the authentication type, encryption level, and the IMAP port if it is not the standard port 993 for IMAP. Finally, specify the number of mailboxes to simultaneously migrate. Click next to continue.

If the IMAP settings in Step 7 are correct and Exchange Online can connect to the on-premises server through IMAP, the wizard will use the information to create a migration endpoint. On the Confirm the migration endpoint page, click next.

After the migration endpoint has been successfully created, the information about the endpoint will be displayed on the IMAP migration configuration page. Click next.

On the Move configuration page, provide a name for the migration batch, and then click next.

On the Start the batch page, click browse to select additional administrators to whom you would like to send a copy of the migration report once the migration is complete.

Select whether to automatically start the batch or to manually start it later. Click new to create the batch.

After migration is complete, modify your MX record to point to Office 365 Exchange Online.

Migration using remote Windows PowerShell

Windows PowerShell can be used to initiate cutover or staged migrations. The commands are slightly different depending on whether you are using the latest release of Office 365 or not.

During the migration, you can monitor the progress by entering the following command:

Get-MigrationBatch | fl Status

INSIDE OUT: Cutover migration best practices

Plan to do a cutover migration over a weekend and change the MX record as soon as the cutover migration is successfully completed. Remember that cutover migrations are for organizations with 1,000 or fewer mailboxes, and even though there is a final synchronization, it is common for mailboxes to be missing items between synchronizations if a cutover migration is left in synchronized mode for an extended period of time. Therefore, plan to complete a cutover migration in a single pass and switch the MX records as soon as possible. It also helps if prior to the migration you set the Time to Live (TTL) for your MX records to be fairly short, thereby reducing the time required for Domain Name System (DNS) convergence. The Complete-Migration cmdlet is deprecated as of April, 2012. For more information, seehttp://community.office365.com/en-us/blogs/office_365_technical_blog/archive/2012/04/04/why-administrators-don-t-see-the-complete-migration-button-in-the-e-mail-migration-tool.aspx.

Using remote Windows PowerShell with the latest release of Office 365 with Exchange Online 2013

Follow these steps to initiate a migration to Exchange Online 2013 using remote Windows PowerShell:

Start the migration batch automatically by adding the –AutoStart parameter to the commands in Step 3 or 4. Otherwise, you can manually start the migration batch by entering the following command:

Start-MigrationBatch -Identity $StagedBatch.Identity

or

Start-MigrationBatch -Identity $CutoverBatch.Identity

Migration with an Exchange hybrid environment

Migration after establishing an Exchange hybrid environment is one of the most popular approaches because, unlike the other methods we have covered so far, after you establish an Exchange hybrid environment, you can move mailboxes to the cloud and back to on-premises. Part of setting up an Exchange hybrid environment is to implement an Exchange 2010 Service Pack 3 (SP3) Client Access Server (CAS). This introduces the Mailbox Replication Service (MRS) that comes with the 2010 SP3 CAS. MRS is the service responsible for carrying out mailbox moves.

In Chapter 11, we discussed in depth how an Exchange hybrid model is implemented. As such, we will not be covering the steps again here.

Microsoft Exchange PST Capture

With Exchange Online, your users have large mailboxes with access to a personal archive. As mentioned before, this makes personal folders (.pst) files obsolete. If your organization has .pst files, in addition to migrating mailboxes you might have to search for .pst files on computers in your organization so you can incorporate the contents into personal archives. This can be accomplished with Microsoft PST Capture.

PST Capture works with Exchange on-premises and Exchange Online. Therefore, you have two import options:

Discover .pst files and import contents to an on-premises Exchange server first, then migrate mailboxes to Exchange Online. In this scenario, the on-premises Exchange server must be Exchange 2010 or Exchange 2013.

Discover .pst files and import contents directly to Exchange Online.

PST Capture comprises the following components:

PST Capture Central Service The Central Service maintains the list of .pst files found in your organization and manages the migration of the data into Exchange Online.

PST Capture Agent This is the component that needs to be installed on computers in your organization and is responsible for locating .pst files associated to the computer it is installed on. The agent is also responsible for transmitting the .pst file to the Central Service during import operations.

PST Capture Console The PST Console is the administrator interface to configure .pst discovery, configure the import process, and also import .pst files from network storage devices that do not have capture agents installed.

Use a user account that is part of the local Administrators Group of a host computer to install the PST Capture Console. The host computer must have a 64-bit operating system that is Windows 7 or Windows 8, Windows Server 2008, Windows Server 2008 R2, or Windows Server 2012. It also must have the .NET Framework 4.5.

Next, you need to deploy the agents. Even though you can manually install the PST Capture agent, to distribute it to multiple computers you need to use a software distribution solution such as System Center Configuration Manager. You can start Windows installer with the following parameters to initiate an unattended installation:

Before searching for .pst files, you need to specify your online connection settings. From the Tools menu, select Settings.

On the Settings page, under Online Connection, provide the credentials of an Office 365 administrator account.

If you are migrating .pst content directly to Office 365 Exchange Online, select the The above is an Office 365 Server check box and provide the server name. To determine your Exchange Online server name, use the ECP by going to OWA, selecting Options, selecting See All Options, and clicking the Settings for Post Office Protocol (POP), IMAP, and SMTP access link, as shown in Figure 12-25.

After you have entered the information in the Online Connection Settings page, click Check. If the PST Capture Console can connect to Exchange Online with the credentials, you will see the “Successfully connected to Exchange Online” message, as shown in Figure 12-26. Click OK to save the settings and close the window.

Figure 12-26 Successfully connected to Exchange Online.

Click New PST Search to invoke the New PST Search Wizard, as shown in Figure 12-27. Note that there are four steps. At the first step, select the Computers node, and then click Next.

In Step 3 of the New PST Search Wizard, you can choose to schedule this search at an off-peak time by specifying the date and time, or you can accept the default of No schedule so you can manually start this search. Click Next.

In the last step of the New PST Search Wizard, give the search a name, as shown in Figure 12-29, and then click Finish.

A new PST Search is created, and the details are displayed in a separate tab in the PST Search Console, as shown in Figure 12-30. Note the following key information: Number of computers included in the search scope, the status of each task, and whether the search is scheduled or not. Also, make sure the agent is detected for the computers that are in this PST Search. There is a Search All Now button you can use to invoke this search. Click this button to manually start the search now.

When the search is complete, the status beside each computer selected will be Completed and the number of PST files found, if any, will be listed in the Files Found column together with the total size of all the PST files found on the computer. Figure 12-31 shows the results of a computed PST search.

Select the .pst files you want to import by selecting the check boxes. Then click the New Import List button at the bottom of the page.

You will see a drop-down list with two options: Cloud Import List and OnPrem Import List. As mentioned before, you can use PST Capture to import content from .pst files to an on-premises Exchange server or directly into Exchange Online. For this exercise, select Cloud Import List.

Set the .pst files to a destination mailbox by clicking the Set mailbox link, as shown in Figure 12-32. A list of mailboxes will be listed in a separate window. Select the destination mailbox from the list, and then click OK.

If you recently set the online connection settings (Step 8), the Set Mailbox window might be empty. This is because the PST Console has not retrieved a list of all the mailboxes on Exchange Online. Wait for a while, and then try again. Depending on the number of mailboxes in Office 365, it might take some time.

Click the Import All Now button to start importing .pst contents to the respective destination mailboxes.

Although we did not cover all the settings for the PST Capture Console, you can explore the different options available, such as setting the staging area, import tolerance, and whether to import non-mail items such as calendars. Click Tools from the PST Capture Console menu and select Settings. Next, review the available settings options and configure them to meet your organization’s needs.

Third-party migration tools

If for some reason the existing tools and options provided by Microsoft do not meet your migration needs, there are always third-party tools you can turn to. Examples of third-party Exchange migration tools are Quest Software, Binary Tree, BitTitan, Cemaphore, and Metalogix. Exchange is a mature platform and has been around for some time. Therefore, third-party tools are readily available and are just as mature.

Migration best practices

There are several best practices when migrating mailboxes. We will list some of the common ones you should consider adopting when migrating mailboxes from on-premises mail servers to Exchange Online.

Reduce the TTL for MX records

In most scenarios, you will want to route incoming email to Exchange Online. Therefore, before starting any of the migration tasks, regardless of whether it is a cutover, staged, or IMAP migration, change the Time To Live (TTL) of your MX records so as to improve the DNS convergence time when you do switch your MX records. The recommendation is that you change the TTL to 3,600 seconds, which is one hour.

Migration performance

There are many factors that affect migration performance, such as the size and number of items in the mailboxes, network bandwidth, network latency, and the on-premises mail servers. Migration performance can also be affected by the time of day and the number of users on the network. That is why you should carry out migrations after the work day is done or over weekends. As an example, after initial tests with a small staged migration batch, Microsoft Consulting Services generally aims to ramp up to a migration rate of 1,000 mailboxes a week, mostly conducted after business hours when network utilization is at the lowest level.

As we mentioned in Chapter 2, bandwidth is not necessarily the only factor. Latency and sustained throughput are factors that are just as important when it comes to migration performance. For an idea on how much throughput is required for the different types of migration options we covered in this chapter, refer to the Migration Performance white paper referenced in the following Inside Out sidebar. In the Migration Performance white paper, an important metric to note is that past experience has shown that a 5 GB to 10 GB per hour rate of data migration can be reliably achieved, but depends on the Internet connection.

INSIDE OUT: “Migration Performance” white paper

Microsoft has provided an excellent TechNet article about migration performance based on experience and observations from actual customer migrations to Office 365. The “Migration Performance” white paper is located at http://technet.microsoft.com/en-us/library/jj204570.

If you are going to use Microsoft PST Capture, you can import the .pst files to your on-premises mailbox first and then do a migration, or you can import the .pst files directly to cloud mailboxes. PST imports are bandwidth-intensive operations, so you need to take that into consideration when scheduling and designing your PST import strategy.

Migration service throttling

In the migration exercises that you looked at earlier in this chapter, recall that you have the ability to specify the number of mailboxes that are migrated simultaneously, which by default is three. Specifying the number of mailboxes that should be simultaneously migrated is referred to as migration-service throttling.

Refer again to the “Migration Performance” white paper or test a single mailbox migration to determine the migration throughput. This will help you determine the optimum number of simultaneous migrations your network can support.

User throttling

User throttling mostly affects third-party migration tools. User throttling limits the number of mailboxes a user can access simultaneously and is designed to minimize risks and preserve resources. Therefore, if a migration tool uses a single service account with access to all mailboxes, Office 365 might throttle the service account if it starts to access too many mailboxes simultaneously during the migration process, thereby impacting migration performance. When you evaluate migration tools, make sure that performance will not be impacted by user throttling. Good migration tools generally use Exchange Web Services to impersonate user accounts so Exchange Online is not seeing a single user simultaneously accessing multiple mailboxes, but rather the users accessing their respective mailboxes. Thus, user throttling will not be triggered.