self-service mailbox migration in exchange online dedicated · client access servers (if configured...

Dedicated and ITAR-support Plans

Self-Service Mailbox Migration in Exchange Online Dedicated

Applies to: Office 365 Dedicated - Legacy 2013 Platform Release

Topic Last Modified: 31-Jan-2013

Topic Last Modified: Modifications Applied:

31-Jan-2013 Initial Release

Mailbox Migration is a self-service feature of the Exchange Online dedicated and ITAR-support plans of Office 365

for enterprises. The Exchange Admin Center (EAC) is used to initiate, manage, and monitor the movement of

mailboxes between on-premises environments and Exchange Online. Topic areas described within this self-service

migration guide are the following:

What is Self-Service Mailbox Migration? 4

Infrastructure Requirements 5

Hybrid Server 5

Network Connectivity 5

Active Directory Synchronization 5

Client Systems 6

Mailbox Migration to/from Exchange Online Dedicated 6

What do you need to know before you begin? 7

On-premises Exchange Server Configuration 7

On-Premises Permissions to Migrate Mailboxes 7

Exchange Online Dedicated Permissions to Migrate Mailboxes 8

Mailbox Preparation 8

Step 1: Create a migration endpoint 9

What do you need to know before you begin? 10

Create a migration endpoint for migrations in an Exchange hybrid deployment 10

How do you know this worked? 13

Step 2: Enable the MRS Proxy 13

Step 3: Create and execute migration batch to move mailboxes 13

Use EAC to manually select and move mailboxes 13

Use remote Windows PowerShell to manually select and move mailboxes 15

Use of a .csv input file for mailbox moves 15

Step 4: Remove completed migration batches 15

Step 5: Re-enable offline access for Outlook Web App 15

Self-Service Migration in Exchange Online Dedicated

© 2015 Microsoft Corporation. All rights reserved.

2

How do you know this worked? 15

Manage Migration Batches in Exchange Online 17

Migration Dashboard 17

Overall migration statistics 18

Migration batches 19

Commands 20

Migration batch statistics 21

Migration Users Status Report 23

Migration users report 23

Columns in the list of migration users 24

Migration user statistics for a specific user 24

Migration phases 26

Migration Cmdlets 27

Appendix A – Factors that affect Exchange Online Dedicated migration performance 30

Overview of Exchange Online Dedicated email migration 30

Migration methods available with Exchange Online Dedicated 30

Summary of observed migration performance 31

Overview of Exchange Online email migration performance factors 31

Common migration performance factors 32

Network performance factors 33

Office 365 resource health-based throttling 34

Native Office 365 hybrid migration 34

Migration performance factors and best practices 34

Appendix B – Using a CSV File for Mailbox Migration 40

Supported attributes for CSV files for bulk moves or migrations 40

On-boarding remote move migrations in a hybrid deployment 41

Off-boarding remote move migrations in a hybrid deployment 42

Attribute values in the CSV file override the values for the migration batch 45

Appendix C – Mailbox migration in a multi-region environment 47

Preparation 47

Execution 48

Verification 48

Troubleshooting 49



3

Important

1. Preview material may be updated periodically before becoming a published version within the

Exchange Online Dedicated area of the Microsoft TechNet Library. Rather than downloading or

printing the content, viewing the material at this site is recommended whenever reference

information is needed.

2. Not all generally available documentation produced by Microsoft to describe the features and

functionality of Exchange 2013 is applicable to the dedicated and ITAR-support plan offerings of

Office 365 for enterprises. Content accessible via links provided in this content are reliable sources.

3. Unless otherwise stated, all references to “dedicated plans” or “Exchange Online Dedicated” also

apply to the International Traffic in Arms Regulations (ITAR-support) version of Exchange Online.

http://technet.microsoft.com/en-us/library/dn456365(v=exchg.150).aspx



4

What is Self-Service Mailbox Migration? The process to migrate mailboxes between an on-premises environment and Exchange Online Dedicated involves

establishing the required infrastructure, applying required Active Directory updates for the user objects representing

each mailbox, and using specific tools to execute the migration.

When an Exchange hybrid deployment has been established to bridge the on-premises and online Exchange

organizations, user mailbox data then can be migrated from an on-premises Exchange 2013, Exchange 2010, Exchange

2007, or Exchange 2003 mail server to Exchange Online Dedicated. The movement of mailboxes aligns with the

following processes:

On-boarding remote move migration: Allows mailboxes from an on-premises Exchange organization or

the multi-tenant version of Exchange Online to be moved to Exchange Online Dedicated. The process is also

known as an on-boarding remote move migration because you onboard mailboxes to Exchange Online.

Off-boarding remote move migration: Allows mailboxes from an Exchange Online Dedicated

organization to be migrated to an on-premises Exchange Server or to the multi-tenant version of Exchange

Online. The process is known as off-boarding.

Notes

1. Both on-boarding and off-boarding remote move migrations involving an on-premises

Exchange organization are initiated from your Exchange Online organization. If the off-

boarding source or on-boarding target is the multi-tenant version of Exchange Online, the

EAC migration tool must be launched from within the multi-tenant environment and the

required Migration Endpoint (Exchange Online Dedicated) must be indicated and or created.

2. Only mailbox-enabled users within the on-premises Exchange or Exchange Online Dedicated

environment can be migrated.

3. To migrate mailboxes from an on-premises environment to multiple geographic regions

supported by Exchange Online Dedicated, the Exchange CustomAttribute for each on-

premises mailbox user (a.k.a. the Extension Attribute of a user object held in Active Directory)

must be set. See the SetMailboxType section of the Office 365 Dedicated and ITAR-support

Plans Provisioning Tools Handbook held within the Customer Extranet site for additional

information. Once the attribute has been set, the migration feature will automatically route

the mailbox to the correct region.



5

Infrastructure Requirements

Hybrid Server

The initial on-boarding of user mailbox data requires the use of a separate on-premises Exchange Server referred to

as a hybrid server to bridge the on-premises and online Exchange organizations. A hybrid server can be used to

support just the migration of mailboxes during the migration period or it can be used in a long term coexistence

configuration to support migrations as well as the presentation of calendar free/busy availability and calendar

sharing between the on-premises and online organizations.

The requirements for the hybrid server are described in Exchange Server 2013 Hybrid Deployment for Exchange

Online Dedicated. After a hybrid configuration has been chosen and implemented, specific processes must be

followed and specific tools must be used to perform the mailbox migrations.

Network Connectivity

You must verify that network connectivity exists between the Exchange Online Dedicated organization and your on-

premises Exchange organization. Connectivity can be via the dedicated networking facilities between Exchange

Online Dedicated and your on-premises systems, via the Internet, or a combination of both.

Active Directory Synchronization

The Microsoft Managed Solutions Services Provisioning Provider tool (MMSSPP – commonly referred to as

“Mississippi”) is used to propagate on-premises Active Directory object data to the Active Directory of Office 365

Dedicated. To support an on-boarding migration of your on-premises mailboxes to Exchange Online Dedicated, a

corresponding object must exist in the Active Directory of Office 365 Dedicated. For additional information

describing how provisioning is implemented within Office 365 Dedicated, how MMSSPP functions, and how to

initially configure your on-premises Active Directory for MMSSPP synchronization, see the MMSSPP & Provisioning

Tools landing page within the Customer Extranet site to access the links to the MMSSPP Customer Deployment

Guide, MMSSPP Identity Synchronization Handbook, and the Office 365 Dedicated and ITAR-support Plans

Provisioning Tools Handbook.

Note

If MMSSPP must synchronize any user objects that have mailboxes in Exchange environments that

are hosted in other Active Directory forests (i.e., not the primary forest being used for the MMSSPP

synchronization), these objects must have all of their Exchange service specific settings (e.g.,

PublicDelegates, msExchRequireAuthToSendTo, authoring, etc.) copied to the Active

Directory object in the forest from which MMSSPP synchronizes. See Appendix B of the MMSSPP

Identity Synchronization Handbook for a complete list of the attributes by object type that are

currently supported for synchronization by MMSSPP.

https://sharepoint.partners.extranet.microsoft.com/sites/MMS%20Knowledge%20Base/Release%20Docs/Exchange/E15%20Readiness/Content/Exchange%20Server%20Hybrid%20Deployment%20for%20Exchange%20Online%20Dedicated.mht

https://sharepoint.partners.extranet.microsoft.com/sites/MMS%20Knowledge%20Base/Release%20Docs/Exchange/E15%20Readiness/Content/Exchange%20Server%20Hybrid%20Deployment%20for%20Exchange%20Online%20Dedicated.mht

https://sharepoint.partners.extranet.microsoft.com/sites/MMS%20Knowledge%20Base/Release%20Docs/MMSSPP/MMSSPP%20Rel%20Docs.htm




6

To gain an understanding of the object attributes you will need to populate in your on-premises Active Directory to

support an off-boarding migration, see the attribute listings shown in Prepare Mailboxes for Cross-Forest Move

Requests. If a large scale on-boarding or off-boarding if mailboxes is required due to a corporate divestiture,

merger, or acquisition, contact your Service Delivery Manager for additional guidance.

Client Systems

Prior to the start of the migration, all client systems must be confirmed to be compliant for use with Exchange

Online. See the client system software requirements description of the Client and Application Connectivity section of

the Exchange Online Dedicated Service Description.

Mailbox Migration to/from Exchange Online Dedicated Within Exchange Online Dedicated, individual or multiple mailboxes can be migrated using the Exchange Admin Center

(EAC) or remote Windows PowerShell. Exchange Online Dedicated is used to manage mailbox migration in either

direction between the on-premises and online environments via the hybrid Exchange server within in your on-premises

environment. As described in the Infrastructure Requirements section above, you must have an Exchange hybrid

server deployed to use the remote move migration method for migrations to/from the on-premises

environment. Mailbox migration between the multi-tenant and dedicated versions of Exchange Online does not

require the use of a hybrid server.

The remote move migration method is used to migrate mailboxes via an on-premises Exchange hybrid server. The

execution of mailbox migrations is invoked as a batch. The batch can be created by manually selecting one or more

mailboxes from the source forest or by preparing a Comma Separated Values (.csv) file that lists the mailboxes to be

migrate. The .csv file can be uploaded into EAC or used by the New-MigrationBatch cmdlet from within remote

Windows PowerShell.

Notes

1. Both on-boarding and off-boarding remote move migrations involving an on-premises Exchange

organization are initiated from your Exchange Online organization. If the off-boarding source or on-

boarding target is the multi-tenant version of Exchange Online, the migration must be launched from

within the multi-tenant environment, the required Migration Endpoint (Exchange Online Dedicated) must

be created, and this endpoint must be referenced when invoking the migration. Other configuration steps

also must be addressed to initiate a migration involving the multi-tenant version of Exchange Online –

contact your Service Delivery Manager for assistance.

2. If a user has an archive mailbox either as an element of a standard active mailbox account or while on

Legal Hold, both the primary and archive mailboxes will be migrated.

3. For a configuration involving the presence of Lotus Domino mailboxes on-premises, see the Planning,

Deployment, and Migration section of the Exchange Online Dedicated Service Description for a description

of migration services offered for this mailbox type.

http://technet.microsoft.com/en-us/library/ee633491(v=exchg.150).aspx


http://technet.microsoft.com/en-us/library/jj891035.aspx





7

What do you need to know before you begin?

In addition to the infrastructure requirements described above, the collection of requirements included below must

be met prior to the start of mailbox migrations.

On-premises Exchange Server Configuration

The mailbox Replication Service Proxy (MRS Proxy) must be enabled on your on-premises Exchange 2010/2013

Client Access servers (if configured to fulfill the hybrid server role) or on your standalone hybrid Exchange server if

your on-premises mail server is Exchange 2003/2007. Also, the Exchange 2010/2013 Client Access server of your

hybrid deployment must be configured to send and receive network traffic on Port 443 from the 141.251.0.0/16

subnet (mailbox migration data will be transferred between Exchange Online Dedicated and the customer

environment on Port 443).

On-Premises Permissions to Migrate Mailboxes

When you migrate on-premises Exchange mailboxes to and from Exchange Online Dedicated, the on-premises

account that you use to connect to your on-premises Exchange organization during the migration must have the

necessary permissions to access, and in some cases modify, the on-premises mailboxes that you want to migrate.

The account, referred to as the migration administrator, is used to create a migration endpoint for your on-

premises organization. To successfully create a migration endpoint (or to create a migration batch if no migration

endpoints exist in your Exchange Online organization), the migration administrator account must align with at least

one of the following permission options within your on-premises Exchange organization:

The migration administrator must be a member of the Domain Admins administrative group in Active

Directory in the on-premises organization; or

The migration administrator must be a member of the Exchange Recipients Administrators admistrative

group in Active Directory in the on-premises organization AND be a Local Administrator on all Client Access

Servers that will be used as migration MRS Proxy endpoints; or

If you have an on-premises Exchange 2010 and Exchange 2013 organization, the migration administrator

must be a member of the Organization Management or Recipient Management built-in role group (the

default roles associated with the built-in role groups and the original exposed cmdlets/parameters for these

groups are assumed to exist) AND be a Local Administrator on all Client Access servers that will be used as

migration MRS Proxy endpoints.

You can use the Exchange Management Shell in your on-premises organization to assign the necessary

permissions to migrate mailboxes to Exchange Online.



8

Notes

Since Exchange Server 2003 does not support the Exchange Management Shell, you have to use the Active

Directory Users and Computers view to grant Full Access permission and also use Exchange Server

Manager to assign the Receive As permission. For more information, see the following:

How to assign users or groups full access to other user mailboxes

How to assign service account access to all mailboxes in Exchange Server 2003

Exchange Online Dedicated Permissions to Migrate Mailboxes

In addition to establishing appropriate access to the on-premises Exchange environment, you need to be a

member of the Mailbox Migrations role group within Exchange Online Dedicated. A self-service administration

account is used to initiate and manage cross-forest remote move migrations to Exchange Online. See the Self-

Service Administration content within the Exchange 2013 Platform Readiness area of the Customer Extranet site

for additional information.

Mailbox Preparation

The size of a mailbox and available network bandwidth are limiting factors in achieving a high migration velocity. A

common practice to reduce the size of the mailbox is to move email items out of the mailbox to an archive (e.g., a

.PST file) either manually or with auto-archive functionality. To reduce mailbox size, the following actions are

recommended:

Delete or archive mail in the Sent Items folder.

Delete or archive all Calendar attachments.

Delete or archive Calendar items over 30 days old.

Delete or archive Inbox items over 90 days old.

Search for and delete attachments over 5 MB.

Disable Journaling.

Empty the Deleted Items folder.

Run the Mailbox Cleanup wizard from the Outlook Tools menu (Outlook only).

Notes

1. If the mailbox owner moves the mail items back to the new Exchange Online mailbox after migration,

the Exchange Online mailbox will not allow the user to reply to these mail items.

2. The day span and file sizes described in the bullet list above are recommendations only; these values

may not be suitable for your organization.

http://go.microsoft.com/fwlink/p/?linkid=3052&kbid=268754

http://support.microsoft.com/kb/821897/en-us

https://sharepoint.partners.extranet.microsoft.com/sites/MMS%20Knowledge%20Base/Release%20Docs/Exchange/E15%20Readiness/main.html



9

Your organization will need to assess the number of mailboxes, size of each mailbox, and the rate of mailbox size

growth in your existing environment. The information obtained will help you evaluate the impact of migration traffic

on your network. If your organization enforces maximum mailbox size limits, this information also is important to

consider when you define Exchange Online storage capacities. Your new Exchange Online environment should let all

users store the same amount of data allowed for their mailbox and also be size to accommodate growth. You

should also confirm if the capacities of your Exchange Online plan(s) support your existing mailbox inventory. Each

Exchange Online Dedicated plan supports a specific mailbox storage level. For more information, see the Standard

Messaging Plan Mailboxes description of the Mailbox Features section of the Exchange Online Dedicated Service

Description.

For additional recommendations to streamline the migration process, see Appendix A – Factors that affect Exchange

Online Dedicated migration performance. If assistance is required to support any level of migration planning and

preparation, contact your Service Delivery Manager to gain access to additional Microsoft resources.

Step 1: Create a migration endpoint

A migration endpoint is a management object that contains the connection settings and administrator credentials

for your on-premises environment. The migration endpoint also defines the number of mailboxes to migrate

simultaneously during initial synchronization and the number of mailboxes to synchronize simultaneously during

incremental synchronization (occurrence once every 24 hours for selected migration types). During incremental

synchronization, on-premises and Exchange Online mailboxes are synchronized so that new email sent to mailboxes

on the source server is copied to the corresponding Exchange Online mailbox.

Prior to the execution of a remote move migration to on-board or off-board mailboxes in an Exchange hybrid

deployment, an Exchange remote migration endpoint must be created. Consider the following:

Recommended is the creation of the migration endpoint in advance followed by selection of the endpoint

when the migration batch is created (Step #3 below).

If no endpoints exist at the time a migration batch is created, you can provide server and remote credentials

when prompted during the batch creation step.

If one or more endpoints have been configured but the endpoint you require is not present in the list of

available endpoints displayed at the time the migration batch is created, you must follow the Use the EAC to

create an Exchange remote migration endpoint instructions below to add your entry to the endpoint

selection list.




10

What do you need to know before you begin?

Estimated time to complete each procedure: 3 minutes.

You need to be assigned permissions before you can perform this procedure or procedures. To see what

permissions you need, see the Mailbox Move and Migration Permissions section in the Recipients

Permissions topic.

When you create a migration endpoint, by default, it will support 20 maximum concurrent migrations during

initial synchronization and a maximum of 10 concurrent incremental synchronizations. You can specify a

different number of concurrent migrations when you create a migration endpoint. To change these settings,

you can edit an existing migration endpoint using the EAC or the Set-MigrationEndpoint cmdlet.

There is a limit of 100 concurrent migrations.

We recommend that you test the connection settings to the server that hosts the mailboxes that you want

to migrate. The connection settings will be tested when you create a migration endpoint; verifying the

settings before you create an endpoint will give you an opportunity to troubleshoot any issues. Run the

following commands using remote Windows PowerShell within Exchange Online Dedicated to test the

connection settings to the source server:

$Credentials = Get-Credential

Test-MigrationServerAvailability –ExchangeRemoteMove –Autodiscover –EmailAddress <email address

for on-premises administrator account> -Credentials $Credentials

For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard

Shortcuts in the Exchange Admin Center.

Create a migration endpoint for migrations in an Exchange hybrid deployment

The migration endpoint contains the connection settings for a Client Access server in your on-premises

Exchange organization.

Note

The same Exchange remote migration endpoint can be used for moving on-premises mailboxes to

Exchange Online or for moving Exchange Online mailboxes to your on-premises organization

Important

You must have a hybrid deployment configured between your on-premises and Exchange Online

organizations to create an Exchange remote migration endpoint and to use remote move migrations to

move mailboxes between your on-premises and Exchange Online organizations. For more information

regarding hybrid deployments, review the Infrastructure Requirements section above.

http://technet.microsoft.com/en-us/library/dd638132%28v=exchg.150%29.aspx

http://technet.microsoft.com/en-us/library/dd638132%28v=exchg.150%29.aspx

http://technet.microsoft.com/en-us/library/jj150484(v=exchg.150).aspx




11

Use the EAC to create an Exchange remote migration endpoint

1. In the EAC of Exchange Online Dedicated, navigate to Recipients > Migration.

2. Click (more) on the EAC toolbar and select Migration endpoints in the pop-up that appears.

3. On the Migration endpoints page, click (add).

4. On the Enter on-premises account credentials page, complete the following boxes:

Email address Type the email address of any user in the on-premises Exchange organization that will

be migrated using this endpoint. Exchange Online will test the connectivity to this user's mailbox.

Account with privileges Type the user name (using the domain\user name format or email address)

for an account that has the necessary administrative privileges in the on-premises organization.

Exchange Online will use the Autodiscover service and this account to detect the migration endpoint

and to test the permissions assigned to this account by accessing the mailbox specified in the previous

box.

Password of account with privileges Type the password for the administrator account that you

specified in the previous box.

5. Click Next. Exchange Online uses the information provided to test connectivity to an on-premises server

and then displays the Confirm the migration endpoint page. Do one of the following based on whether

the connection settings were successfully detected:

o If Exchange Online successfully connects to an on-premises server, the connection settings are

displayed. Click Next.

o If the test connection to an on-premises server isn't successful, you have to enter the fully qualified

domain name (FQDN) of the on-premises server that the MRS Proxy service is running on in your

hybrid deployment (e.g., mail.contoso.com). The MRS Proxy service typically runs on the Exchange

Client Access server in your on-premises organization. You have to successfully connect to an on-

premises server to continue.

Important

Online creates a new migration endpoint using the connection settings that were successfully

discovered or that you provided manually. We recommend that you create migration endpoints whose

connection settings were automatically discovered rather than creating endpoints whose settings you

entered manually. This is because the Autodiscover service will be used to connect to each user mailbox

during the migration. If manual settings are used, Exchange Online won't use the Autodiscover service,

but will connect to a specific source server using the connection settings you manually entered. If you

use manual settings and have multiple on-premises Exchange servers, you may need to create different

migration endpoints that correspond to each server.

7. Click Next. Enter information in the following boxes:

Migration endpoint name - Name displayed in the list of migration endpoints. It's also used in the

drop-down list of migration endpoints when you select a migration endpoint while creating a

migration batch. This is required.



12

Maximum concurrent migrations - Number of connections to the source server that are available to

migrate on-premises mailboxes and mailbox items to Exchange Online during initial and incremental

synchronization. If the value is set to 20, which is the default value, you can migrate up to 20 mailboxes

at the same time.

If multiple migration batches use the same Exchange remote migration endpoint, the maximum

number of concurrent migrations allowed by the migration endpoint is shared across all the migration

batches.

Note

As previously stated, there is a limit of 100 concurrent migrations for all

Exchange remote migration endpoints in your organization.

Maximum concurrent incremental syncs - Number of connections to the source server that are

available to perform incremental synchronizations. If the value is set to 10, the default value, then

incremental synchronization can be performed on up to 10 mailboxes at the same time.

For example, if the endpoint is configured with 100 maximum concurrent migrations and 40 maximum

concurrent incremental syncs, 40 connections can be used for incremental synchronization, if

necessary. The other 60 connections are reserved for initial synchronizations.

8. Click New to create the migration endpoint.

Use the Shell to create an Exchange remote migration endpoint

This example creates a migration endpoint that can be used to support either on-boarding or off-boarding for

remote move migrations. In both cases, the migration endpoint is an Exchange server in your on-premises

Exchange organization that is running the MRS Proxy service – typically the Client Access server. Using remote

Windows PowerShell in your Exchange Online Dedicated environment, execute the steps below.

Note

You must be a member of the Mailbox Migration role group within Exchange Online

Dedicated to execute the New-MigrationEndpoint cmdlet shown below.


New-MigrationEndpoint –ExchangeRemoteMove –Name OnpremEndpoint -Autodiscover –EmailAddress <email

address for on-premises administrator account> -Credentials $Credentials



13

How do you know this worked?

To verify that you've successfully created an Exchange remote migration endpoint, do one of the following:

1. In the EAC, navigate to Recipients > Migration.

2. Click (more) on the EAC toolbar and select Migration endpoints in the pop-up that appears. The

new migration endpoint is displayed in the list, and the endpoint type is Exchange Remote. Alternatively, use

remote Windows PowerShell to run the following command to display information about the migration

endpoint:

Get-MigrationEndpoint <identity> | Format-List EndpointType,RemoteServer,UseAutoDiscover,Max*

Step 2: Enable the MRS Proxy

To allow the on-premises Client Access server to accept incoming remote move requests, you have to enable the

MRS Proxy endpoint. If the MRS Proxy is not already enabled, follow these steps in the EAC:

1. Within the on-premises Exchange organization, open the EAC and navigate to Servers > Virtual

Directories.

2. Select the Client Access server, select the EWS virtual directory, and click Edit.

3. Select the MRS Proxy enabled check box and then click Save.

See Enable the MRS Proxy Endpoint for Remote Moves for additional information including Windows PowerShell

examples.

Step 3: Create and execute migration batch to move mailboxes

You can use the migration dashboard of the EAC or remote Windows PowerShell in Exchange Online Dedicated to

either move existing user mailboxes in the on-premises organization to the Exchange Online organization or to

move Exchange Online mailboxes to the on-premises organization. A Comma Separated Values (.csv) file containing

all mailboxes to be migrated also can be used as input for the EAC or PowerShell options.

Use EAC to manually select and move mailboxes

Within Exchange Online Dedicated, perform the following:

1. Open the EAC and then navigate to Office 365 Dedicated > Recipients > Migration.

2. Click + (add) and then select either of the following:

Migrate to Exchange Online

Migrate from Exchange Online

3. On the Select the users page, click + (add), select the on-premises users to move to Office 365, click +

(add), and then click OK. Click Next.

http://technet.microsoft.com/en-us/library/dn155787(v=exchg.150).aspx



14

4. If moving on-premises mailboxes to Exchange Online Dedicated and migration endpoints have not been

created, the Enter the Windows user account credential page will appear. Enter the on-premises

administrator account name in the On-premises administrator name text field and enter the associated

password for this account in the On-premises administrator password text field. For example,

“corp\administrator” and a password. Click Next.

Note

If you’ve already created a migration endpoint, you’ll receive an endpoint confirmation

prompt for this step. If you’ve created two or more migration endpoints, you must choose

an endpoint from the migration endpoint drop-down menu.

5. On the Confirm the migration endpoint page, verify that the FDQN of your on-premises Client Access

server is listed when the dashboard shows a confirmation of the migration endpoint. For example,

“mail.contoso.com”. Click Next.

Note

The MRS Proxy service on the Exchange Client Access servers automatically throttles the

mailbox move requests when you select multiple mailboxes to move to Exchange Online.

The total time to complete the mailbox move depends on the total number of mailboxes

selected, the size of the mailboxes, and the configuration of the MRS Proxy.

6. On the Move configuration page, enter a name for the migration batch in the New migration batch

name text field. Use the down arrow to select the Target delivery domain for the mailboxes that are

migrating to Office 365 Dedicated. In most hybrid deployments, this is the coexistence SMTP domain

used for Exchange Online organization mailboxes. For example, mgd.contoso.com. To apply specific

migration settings for BadItemLimit and LargeItemLimit, select More Options… in this view. Descriptions of

the limit options can be found in the Parameters section of the New-MigrationBatch cmdlet description

(custom cmdlet version specifically for Exchange Online Dedicated – see Migration Cmdlets below). Click

Next.

7. On the Start the batch page, select at least one recipient to receive the batch complete report. Also select

appropriate batch start and complete options. Select Automatically start the batch and Automatically

complete the migration batch options if custom settings are not required. If start/complete options are

required, see the New-MigrationBatch cmdlet description (custom version specifically for Exchange Online

Dedicated) in the Migration Cmdlets section below. After all start/complete settings have been applied, click

New.

Note

If you must migrate an Inactive mailbox, the mailbox first must be re-enabled as an active mailbox type,

migrated, and then placed back into an inactive status on the destination system.



15

Use remote Windows PowerShell to manually select and move mailboxes

To use remote Windows PowerShell to execute a remote move migration, see the New-MigrationBatch cmdlet

description (custom version specifically for Exchange Online Dedicated) in the Migration Cmdlets section below.

Use of a .csv input file for mailbox moves

You can use a CSV file to bulk migrate a large number of user mailboxes. You can specify a CSV file when you use

the Exchange Admin Center (EAC) or remote Windows PowerShell to create a migration batch. For additional

information, see Appendix B - Using a CSV File for Mailbox Migration.

Step 4: Remove completed migration batches

After your mailbox moves have completed, we recommend the completed migration batches to minimize the

likelihood of errors if the same users are moved again. To remove a completed migration batch:

1. Open the EAC and navigate to Office 365 Dedicated > Recipients > Migrations.

2. Click a completed migration batch, and then click Delete.

3. On the deletion warning confirmation dialog, click Save.

Step 5: Re-enable offline access for Outlook Web App

Offline access in Outlook Web App lets users access their mailbox when they are not connected to a network. The

default Client Access server configuration of Exchange Online Dedicated enables Outlook Web App offline access. If

the feature was enabled for supported Web browsers using group policy settings within the on-premises

environment prior to the migration of mailboxes, the offline access feature will be active following migration to

Exchange Online Dedicated. See Offline access in Outlook Web App 2013 for a description of the offline access

feature including use of the Set-OwaMailboxPolicy cmdlet to enable/disable the feature (an exposed remote

Windows PowerShell cmdlet within Exchange Online Dedicated). See Using Outlook Web App offline for a user level

description of the feature.

How do you know this worked?

You can verify the status of the migration batch by opening the EAC and selecting Office 365 Dedicated >

Recipients > Migration. You can also run the following remote Windows PowerShell cmdlet to verify the status of

the migration batch:

Get-MigrationBatch –Identity <batch name>

Within the EAC, the move status for specific mailboxes within the batch can be viewed by selecting Recipients >

Migration. The Status value is Syncing during the mailbox move and it is Completed when the mailbox has

successfully migrated.

http://blogs.technet.com/b/exchange/archive/2012/11/06/offline-access-in-outlook-web-app-2013.aspx

http://office.microsoft.com/en-us/support/using-outlook-web-app-offline-HA102828007.aspx



16

When the Status entry for the migrated mailbox is Completed, you can verify the result by examining the

properties of the mailbox. For an on-boarding migration, access the EAC of Exchange Online Dedicated, navigate to

the Recipients area, and select the tab that represents the type of mailbox that was migrated, i.e., User for a

standard or shared mailbox or Resource for a resource mailbox. The mailbox should show a Mailbox Type of

Linked. If Exchange Server 2013 is the on-premises version of Exchange to receive off-boarded mailboxes, the

mailbox value type displayed in the on-premises EAC will be User. For either environment, the Windows PowerShell

cmdlet Get-Mailbox can be used to check mailbox status.

Mailbox Type Destination

Exchange Environment

EAC Navigation

in Destination Environment

Mailbox Type Value

Displayed

User Online Recipients > Mailboxes Linked

User On-premises Recipients > Mailboxes User

Resource Online Recipients > Resource Room or Equipment

Resource On-premises Recipients > Resource Room or Equipment

Shared Online Recipients > Mailboxes1 Linked

Shared On-premises Recipients > Mailboxes1 User

1Exchange Online Dedicated does not use the RecipientType and RecipientTypeDetails properties of Exchange Server to

identify shared mailboxes; thus, the shared tab of the EAC is not applicable. A shared mailbox is represented as a user

mailbox within Exchange Online Dedicated. The provisioning attribute for the object that represents a shared mailbox must

be set to include TYPE=SHARED. See the Office 365 Dedicated and ITAR-support Plans Provisioning Handbook for additional

information.




17

Manage Migration Batches in Exchange Online You can use the Migration dashboard in the Exchange Admin Center (EAC) to manage mailbox migrations to

Exchange Online Dedicated. The Migration dashboard displays statistics about the overall migration in addition to

statistics about a specific migration batch. You can create, start, stop, pause, and edit migration batches.

Migration Dashboard

To access the Migration dashboard in the EAC, select Recipients > Migration. The following screenshot identifies

the different areas of the Migration dashboard that you can use to get migration information and manage

migration batches.

Included below are descriptions of the five sections highlighted in the EAC migration Tab view shown above.



18

Overall migration statistics

Click Status for all batches to display the overall statistics about all migration batches that have been created. The

following fields display cumulative information about all migration batches.

Field Description

Total mailboxes The total number of mailboxes from all current migration batches.

Synced mailboxes The number of mailboxes from all migration batches that were

successfully migrated.

Finalized mailboxes The number of mailboxes from all migration batches that have been

finalized. Finalization only occurs when using remote move

migrations to migrate mailboxes between your on-premises

Exchange organization and Exchange Online in an Exchange hybrid

deployment. Mailboxes can be finalized after the initial

synchronization is successfully completed. For more information

about finalizations in remote move migrations, see Complete-

MigrationBatch.

Failed mailboxes The number of mailboxes from all migration batches for which

migration failed.





19

Migration batches

Migration batches that are created are listed in the migration queue. The following columns display information

about each migration batch.

Column Description

Name The name of the migration batch that was defined when the migration batch was

created.

Status The status of the migration batch. The following is a list of the different status

states for migration batches, along with what you can do with migration batches in

each of these states:

Created: The migration batch has been created, but it hasn't been started. In

this state, you can start, edit, or delete it.

Syncing: The migration batch has been started, and mailboxes in the migration

batch are being actively migrated. When a migration batch is in this state, you

can stop it.

Stopped: The migration batch is stopped, and no more mailboxes from the

batch are being migrated. When a migration batch is in this state, you can

restart it.

Synced: The migration batch has completed, and no mailboxes are being

actively migrated. A migration batch in this state may contain errors if

mailboxes weren’t migrated.

Synced with errors: The migration batch has completed, but some mailboxes

failed migration. Mailboxes that were successfully migrated in migration

batches with errors are still synchronized every 24 hours during incremental

synchronization.

Total Indicates the number of mailboxes in the migration batch.

Synced Indicates the number of mailboxes that were successfully migrated.

Finalized The number of mailboxes in the migration batch that have been finalized.

Finalization is only performed for migration batches for remote move migrations in

an Exchange hybrid deployment. For more information about the finalization

process, see Complete-MigrationBatch.

Failed The number of mailboxes in the migration batch for which migration failed. You

can display information about specific mailboxes that have migration errors. For

more information, see Migration Users Status Report.

Important

Migration batches with a status of Synced that have no administrator-initiated activity for

the last 90 days (for example, no administrator has stopped and restarted a migration batch

or edited a migration batch) will be stopped and then deleted 30 days later if no further

action is taken by the administrator.




20

Commands

The Migration dashboard contains a set of commands that you can use to manage migration batches. After you

create a migration batch, you can select it and then click one of the following commands. If a migration batch is in

a status state that isn’t supported by a command, the command is either dimmed or not displayed because it’s

unavailable.

Command Description

New Create a new migration batch. Use this command to migrate on-

premises mailboxes to Exchange Online (also called on-boarding) or

to migrate Exchange Online mailboxes back to your on-premises

Exchange organization in a hybrid deployment.

Edit Edit an existing migration batch. You can change the migration

endpoint used for the migration batch. You can only edit a

migration batch that has a status of Created.

Start Start a migration batch that’s been created. After the batch is

started, the status is changed to Syncing.

Resume Resume the running of a migration batch that was paused and has

a status of Stopped. If there are errors for a migration batch, you

can restart it with this command and Exchange Online will attempt

to migrate the mailboxes that failed.

Pause Stop a migration batch that’s currently running or that’s been

started but has a status of Queued. You can resume incremental

synchronizations by selecting the migration batch and clicking

Resume.

Delete Delete a migration batch after you verify that all mailboxes in the

migration batch have been successfully migrated and that mail is

being routed directly to cloud-based mailboxes after you’ve

configured your MX record to point to Office 365. When you delete

a migration batch, Exchange Online cleans up any records related

to the migration batch and removes it from the list.

More Click this command and then click Migration endpoints to create

new migration endpoints or view and edit existing migration

endpoints. For more information, see Create Migration Endpoints.

Refresh Refresh the Migration dashboard to update the information

displayed for the overall migration statistics, the list of migration

batches, and the statistics for the selected migration batch.



21

Migration batch statistics

The details pane in the Migration dashboard displays the following information about the selected migration batch.

Overall Status

Field Description

Type Indicates the migration type of the selected migration batch. The

value of this field also denotes the type of migration endpoint

associated with the migration batch.

Remote move migration: The migration batch is either an on-

boarding or off-boarding remote move migration in an

Exchange hybrid deployment.

Direction Indicates if mailboxes are being migrated to Exchange Online or to

your on-premises Exchange organization.

On-boarding indicates that mailboxes are being migrated to

Exchange Online. The supported on-boarding migration type

for Exchange Online Dedicated is remote move migrations.

Off-boarding indicates that Exchange Online mailboxes are

being migrated to your on-premises Exchange organization.

Off-boarding remote move migrations are the only type of off-

boarding migration.

Status The current state of the selected migration batch.

Created

Syncing

Stopped

Synced

Synced with errors

See the previous description of each of these states.



22

Mailbox Status

Synced mailboxes The number of mailboxes out of the total number in the migration

batch that have successfully completed initial synchronization. This

field is updated during the migration.

Finalized The number of mailboxes out of the total number in the migration

batch that have successfully been finalized. Finalization only occurs

in on-boarding and off-boarding remote move migrations.

Failed mailboxes The number of mailboxes that failed initial synchronization.

View details Click View details to display status information for each mailbox in

the migration batch. For more information, see Migration Users

Status Report.

Statistics

Field Description

Created by The email address of the Exchange Online administrator who

created the migration batch.

Create time The date and time when the migration batch was created.

Start time The date and time when the migration batch was started. For

batches scheduled with the StartAfter time/date variable set, the

Start time will display as $null as this reflects the time the batch was

initially submitted.

Initial sync time The date and time when the migration batch completed initial

synchronization.

Initial sync duration The amount of time it took to complete the initial synchronization

for all mailboxes in the migration batch.

Last sync time The last time the migration batch was restarted or the last time that

incremental synchronization was performed for the batch.

Associated endpoint The name of the migration endpoint being used by the migration

batch. You can click View details to view the migration endpoint

settings. You can also edit the settings if none of the migration

batches using the endpoint are currently running.



23

Migration Users Status Report You can use the Migration dashboard in the Exchange Administration Center (EAC) to display migration status

information for all mailboxes in a migration batch. You can also display detailed migration information for each user

in a migration batch. This information, also called migration user statistics, can help you troubleshoot issues that

might prevent the migration of a user’s mailbox or mailbox items. You can display this migration status information

for migration batches that are currently running, that have been stopped, or that are complete.

Migration users report

To access the migration users report for a migration batch, select Recipients > Migration, select the migration

batch, and then click View details under Mailbox status in the details pane.



24

The name of the migration batch and the following commands are displayed at the top of the window.

Command Description

Delete Delete the selected user from the list of migration users.

Refresh Refresh the list of migration users to update the information

displayed for the users in the migration batch.

Columns in the list of migration users

Column Description

Email Address The user’s email address.

Status The user’s migration status. See the status descriptions in the table

in the next section.

Items Synced The number of items in the user’s on-premises mailbox that were

successfully migrated to the Exchange Online mailbox.

Items Skipped The number of items in the user’s on-premises mailbox that weren’t

migrated to the Exchange Online mailbox.

Migration user statistics for a specific user

To view status information (also called migration user statistics) for a specific mailbox, mail contact, or distribution

group, click the mailbox, contact, or distribution group in the list. Status information for the selected mail object is

displayed in the details pane. The following table describes each field displayed in the details pane.

Field Description

Status Identifies the specific point in the migration process for each mail

object in the migration batch. This status is more specific than the

high-level status summary displayed in the list of migration users.

The following list describes each status state.

Queued The object is in a migration batch that is running, but

the migration of the object hasn’t started yet. Objects typically

have a status of Queued when all of the connections in the

migration endpoint associated with the migration batch are

being used.

Provisioning The migration process has started for the mail

object, but it isn’t provisioned yet.

Provision updating The mail object has been provisioned, but

not all of the object’s properties were migrated. For example,

after a distribution group has been migrated, this state occurs

when members of the group haven’t been migrated yet or



25

Field Description

there’s a problem migrating a user who is a member of the

group. In this case, the status indicates the migration process

can’t update the group membership because not all group

members have been migrated.

Synced The migration process successfully provisioned the

Exchange Online mailbox and completed the initial

synchronization where all mailbox items were copied to the

cloud-based mailbox. For cutover Exchange migrations and

IMAP migrations, this status can also indicate that incremental

synchronization completed successfully.

Failed The provisioning or the initial synchronization of the

mail object failed. If an Exchange Online mailbox is successfully

created for a user, but the migration of mailbox items fails, the

status for the user will be Failed.

Skipped item details Click Skipped item details to display information about each item

that was skipped for the selected user. The following information

about each skipped item is displayed:

Date The time stamp of the mailbox item.

Subject The subject line of the message.

Kind The type of error that caused the item to be skipped.

Folder name The folder where the skipped item is located.

Data migrated The total amount of data (in bytes and megabytes) for the mailbox

items that have been migrated to the Exchange Online mailbox.

This number includes items migrated in both the initial and

incremental synchronizations. This field doesn't have a value for

IMAP migrations.

Migration rate The average transfer rate (in bytes or MB per minute) of data

copied to the Exchange Online mailbox. This field doesn't have a

value for IMAP migrations.

Error If the migration for the user failed, this field displays a description

of the error. This error description is also included in the Migration

Errors report.

Report Click Download the report for this user to open or save a detailed

migration report that contains diagnostic information about the

migration status of the user. You or Microsoft Support can use the

information in this report to troubleshoot failed migrations.

Last successful sync date The last time that any new items in the on-premises mailbox were

copied to the cloud-based mailbox.



26

Click More details to display the following additional information about the selected migration user.

Field Description

Queued duration The length of time the user had a status of Queued.

In-progress duration The length of time the user was actively being migrated.

Synced duration The length of time the migration user had a status of Synced.

Stalled duration The length of time the migration process was stalled for the user.

You also can use the remote Windows PowerShell in your Exchange Online Dedicated environment to display

migration user statistics using the Get-MigrationUser and Get-MigrationUserStatistics cmdlets. Within the

Exchange Online Dedicated environment, you must be a member of one of the role groups that provides access to

these cmdlets. To locate the role groups, search for the Get-MigrationUser and the Get-MigrationUserStatistics

cmdlets within the Self-Service Administration content held within the Exchange 2013 Platform Readiness area of the

Customer Extranet site for additional information.

Migration phases

To help you understand the migration status states described in the previous sections, it’s helpful to be familiar

with the phases of the migration process. The following table describes these phases and indicates whether the

phase is included in each type of migration.

Migration phase Hybrid Exchange migration

Initial synchronization – The migration

process migrates mailbox items to the newly

cloud-based mailboxes.

Yes

(includes calendar times and contacts)

Incremental synchronization - The migration

process synchronizes the on-premises mailbox

and the corresponding Exchange Online

mailbox every 24 hours.

Yes



https://sharepoint.partners.extranet.microsoft.com/sites/MMS%20Knowledge%20Base/Release%20Docs/Exchange/E15%20Readiness/main.html



27

Migration Cmdlets Remote Windows PowerShell of Exchange Online Dedicated can be used to invoke cmdlets associated with migration

actions. The table below list all migration cmdlets available with Exchange Server 2013 and provides a description of

the subset of cmdlets available within Exchange Online Dedicated. The link provided for each applicable cmdlet points

to its full description within Microsoft TechNet.

Notes

1. To use the migration cmdlets, you need to be a member of specific administrative groups within your on-

premises Exchange organization and your Exchange Online Dedicated environment. See the above sections

Assign Permissions to Migrate Mailboxes to an On-premises Exchange Environment and Exchange Online

Dedicated Self-Service Migration Administrator account for additional information.

2. For the Set-MigrationBatch and New-MigrationBatch cmdlets, the StartAfter and CompleteAfter parameters

have been activated for Exchange Online Dedicated only. The parameter descriptions in the table below

supersede the descriptions shown in the TechNet article for each cmdlet.

Cmdlet Notes

Set-MigrationConfig This cmdlet is not exposed within Exchange Online Dedicated.

Get-MigrationUser

New-MigrationEndpoint

Get-MigrationStatistics

Get-MigrationEndpoint

Set-MigrationEndpoint

Get-MigrationUserStatistics

Set-MigrationBatch

The following exceptions apply to this cmdlet:

The StartAfter and CompleteAfter parameters have been activated for this

cmdlet only within Exchange Online Dedicated – see parameter

descriptions and usage examples below.1

Within the Detailed Description section, only Remote Move is applicable

for Exchange Online Dedicated.

Remove-MigrationEndpoint

Remove-MigrationUser

Complete-MigrationBatch

Export-MigrationReport

Remove-MigrationBatch

Test-

MigrationServerAvailability

Start-MigrationBatch



















28

Cmdlet Notes

Stop-MigrationBatch

Get-MigrationBatch

New-MigrationBatch

The following exceptions apply to this cmdlet:

The StartAfter and CompleteAfter parameters have been activated for

this cmdlet only within Exchange Online Dedicated – see parameter

descriptions and usage examples below.1

Within the Examples section, only example #3 (on-boarding remote

move migration) and example #4 (off-boarding remote move

migration) apply to Exchange Online Dedicated.

Within the Detailed Description section, only the Onboarding

remote move migration and Offboarding remote move

migration descriptions apply to Exchange Online Dedicated.

Get-MoveRequest

New-MoveRequest This cmdlet is not exposed within Exchange Online Dedicated.

Remove-MoveRequest This cmdlet is not exposed within Exchange Online Dedicated.

Resume-MoveRequest

Suspend-MoveRequest

Set-MoveRequest

Get-MoveRequestStatistics

1 Full descriptions of the StartAfter and CompleteAfter parameters and an example of their usage are the

following:

StartAfter Optional System.DateTime The StartAfter switch specifies whether to start the

mailbox move request at a future date and time. If

you use this switch, the request status is Queued

before the start date and time but will not reach the

status of InProgress until after the date and time

specified (see DateTime syntax in Example section).

You cannot set a date greater than 30 days into the

future.

CompleteAfter Optional System.DateTime The CompleteAfter switch specifies whether to

complete the database synchronization request at a

later date and time. If you use this switch, the

request status is Suspended and the request will not

reach the status of InProgress or Completed until

after the date and time specified (see DateTime

syntax in Example section). You cannot set a date

greater than 120 days into the future.




http://technet.microsoft.com/en-us/library/dd335227(v=exchg.150).aspx









29

This example schedules the move of a mailbox to a remote database to start 5 days from the current date and

sets the completion date for database synchronization to take effect 8 days from the current date.

[ As an alternative to using the Get-Date cmdlet, an explicit DateTime pair can be specified in

en-US format (e.g., 12/15/2013 or December 15, 2013 as the date and 7:30:00 PM (12 hour) or

19:30:00 (24 hour) as the time format) or UTC format (20131215193000.000000-480). ]


$MigrationEndpointOnPrem = New-MigrationEndpoint -ExchangeRemoteMove -Name OnpremEndpoint

-Autodiscover -EmailAddress [email protected] -Credentials $Credentials

$OnboardingBatch = New-MigrationBatch -Name RemoteOnBoarding1 -SourceEndpoint

$MigrationEndpointOnprem.Identity -TargetDeliveryDomain cloud.contoso.com -CSVData

([System.IO.File]::ReadAllBytes("C:\Users\Administrator\Desktop\RemoteOnBoarding1.csv")) –

StartAfter (Get-Date).AddDays(5) -CompleteAfter (Get-Date).AddDays(8)



30

Appendix A – Factors that affect Exchange Online Dedicated

migration performance

There are several paths available to migrate data between an on-premises email organization and Exchange Online

Dedicated. The following are the characteristics of the migration performance facts and migration velocity best

practices provided:

Details about how to migrate data and performance issue troubleshooting steps are not addressed.

High level descriptions are provided of external and on-premises factors; additional detail is provided for

Microsoft products and services.

The basis of the descriptions assumes there are no functional issues, connectivity exists between the source and

destination environments, and it is possible to successfully complete a migration between the two

environments.

Overview of Exchange Online Dedicated email migration

Exchange Online Dedicated provides a remotely hosted messaging solution based on Microsoft Exchange Server

2013. A feature of Exchange Online is the capability to migrate email, calendar, and contact data from your existing

messaging environment.

Migration methods available with Exchange Online Dedicated

Migration

tool

Description Example

Native

Office 365

simple

Exchange

migration

A built-in migration tool that

supports remote move migrations.

Migrating mailboxes between on-premises and

Exchange Online Dedicated via an Exchange hybrid

server or migrating mailboxes between the multi-

tenant version of Exchange Online and Exchange

Online Dedicated.

Client

uploading

Data can be uploaded from

various email clients that are

compliant with Office 365. This

method is mostly used on a small

scale and performed by individual

end users.

The user uploads an Outlook personal data file

(PST) from the Outlook client.



31

Summary of observed migration performance

The following table compares the performance observed by Microsoft for methods available to migrate mailboxes

and mailbox data to the multi-tenant version of Office 365. The values shown can be used to determine an

approximate throughput for an Exchange Online Dedicated migration. Migration performance is a function of

several factors as described in the Overview of Exchange Online email migration performance factors section

below.

Migration

tool

Migration

method

Office 365

user

throttling

Office 365

migration-service

throttling

Office 365

resource

health-based

throttling

Observed average

throughput per hour and

per client (if applicable)

Native

Office 365

Hybrid

migration

No Yes Yes 10-15 GB (per on-premises

Exchange 2010 CAS (MRS

Proxy) with 20 concurrent

moves) *

Client

uploading

Outlook Yes No Yes 0.5 GB

Overview of Exchange Online email migration performance factors

Data migration is a complicated process. A summary of potential impacts is described within this section.

* Observed single mailbox move throughput is in the 0.3–1.0 GB/hour range. More concurrent

mailbox migrations can be used to achieve higher data migration rates. For example, with 50

concurrent moves, the overall throughput will be in the 15–50 GB/hour range. Single mailbox

move throughput will slow down when the on-premises CAS (MRS Proxy) server is at hardware

capacity. Consider adding more servers to increase migration velocity



32

Common migration performance factors

The following table provides a list of common factors that affect migration performance. More details are covered

in the sections on the individual migration methods.

Factor Description Example

Data source The device or service that hosts the

data to be migrated. Many

limitations might apply to the data

source because of hardware

specifications, end-user workload,

and back-end maintenance tasks.

Third party providers hosting

Exchange mailboxes may limit how

much data can be extracted during a

specific period of time.

Data type and density Because of the unique nature of a

customer’s business, the type and

mix of mail items within mailboxes

vary greatly.

One 4-GB mailbox with 400 items,

each with 10 megabytes (MB) of

attachments, will migrate faster than

one 4-GB mailbox with 100,000

smaller items.

Migration server Many migration solutions use a

"jump box" type of migration server

or workstation to complete the

migration.

Customers often use a low-

performance virtual machine to host

the migration server.

Migration engine The data migration engine that is

responsible for pulling data from the

source server converts data if

necessary, transmits the data over

the network, and injects the data into

the Exchange Online mailbox.

Microsoft Exchange Mailbox

Replication Service (MRS).

Network The end-to-end network

performance—from the data source

to Exchange Online client access

servers—affects migration

performance.

Firewall on customer egress point.

Office 365 service Office 365 has built-in support and

features to manage the migration

workload.

The user throttling policy limits the

maximum data transfer rate.



33

Network performance factors

This section describes best practices for improving network performance during migration. The discussion is

general because the biggest impact on network performance during migration is related to third-party hardware

and network configuration.

Performance factor Description Best practices

Network capacity The amount of time it takes to

migrate mailboxes to Exchange

Online is determined by the available

and maximum capacity of your

network.

Identify your available network

capacity and determine the

maximum upload capacity.

Use tools to evaluate your actual

network capacity. Make sure you

test the end-to-end flow of data,

from your on-premises data

source to the Microsoft data

center gateway servers.

Identify other loads on your

network (for example, backup

utilities and scheduled

maintenance) that can affect your

network capacity.

Network stability If the network is unstable, data

transfer takes longer because of

error correction. Depending on the

migration type, error correction can

significantly affect migration

performance.

Network hardware and driver

issues often cause network

stability problems. Work with

your hardware vendors to

understand your network devices

and apply the vendor’s latest

recommended drivers and

software updates.

Network delays Possible sources of network delays

that impact migration performance

include the following:

Configuration of network firewall

equipment

Use of the Internet (if required

for your migration)

Mailboxes being migrated from

several geographically dispersed

datacenters

Performance of your ISP (if

Exchange mailboxes are being

hosted by a third party)

Evaluate network delays to all

potential Microsoft data centers

to help ensure that the result is

consistent (this also helps ensure

a consistent experience for end

users). Work with your ISP to

address Internet-related issues.

Add IP addresses for Microsoft

datacenter servers to your allow

list or bypass all migration-

related traffic from you network

firewall.



34

Office 365 resource health-based throttling

Health-based resource throttling is the last gatekeeper to ensure Office 365 service health and availability is

maintained. All migration methods are subject to the governance of availability throttling. Office 365 service

throttling does not affect Office 365 migrations as much as the other types of throttling described in the previous

sections.

Resource health-based throttling is the least aggressive throttling method and occurs only when there is a service

availability issue that affects end users and critical service operations. For example, if a service incident occurs during

a hybrid migration and the service degrades to the point where end-user performance is degraded, the hybrid

migration will be queued until performance has recovered and the service returns to a level below the throttling

threshold. The following is an example from an Exchange migration statistics report that shows an entry caused

when the service-throttling threshold is exceeded:

1/25/2012 12:56:01 AM [BL2PRD0410CA012] Copy progress: 723/1456 messages, 225.8 MB (236,732,045

bytes)/416.5 MB (436,712,733 bytes).

1/25/2012 12:57:53 AM [BL2PRD0410CA012] Move for mailbox '/o=ExchangeLabs/ou=Exchange Administrative

Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx' is stalled because

DataMoveReplicationConstraint is not satisfied for the database 'NAMPRD04DG031-db081' (agent

MailboxDatabaseReplication). Failure Reason: Database edbf0766-1f2a-4552-9115-bb3a53a8380b doesn’t

satisfy constraint SecondDatacenter. There are no available healthy database copies. Will wait until

1/25/2012 1:27:53 AM.

1/25/2012 12:58:24 AM [BL2PRD0410CA012] Request is no longer stalled and will continue.

Native Office 365 hybrid migration

Native Office 365 hybrid migration supports migrations between on-premises Exchange 2003, Exchange 2007,

Exchange 2010, and Exchange 2013 servers and Exchange Online Dedicated. Hybrid migration is the fastest

migration method to migrate mailbox data to Office 365.

Migration performance factors and best practices

The table below provides a list of factors that apply to native Office 365 hybrid migration scenarios.



35

Factor 1: Data source (Exchange Server)

Checklist Description Best practices

System performance Data extraction is an intensive task.

The source system must have

sufficient resources, such as CPU

time and memory, to provide better

migration performance. At the time

of migration, the source system is

usually close to full capacity to serve

regular end-user workload—

additional migration workload

sometimes even brings down end

users' access because of a lack of

system resources.

Monitor system performance

during a pilot migration test. If

the system is busy, we

recommend avoiding an

aggressive migration schedule

for the specific system because

of potential migration slowness

and service availability issues. If

possible, enhance the source

system performance by adding

hardware resources and reducing

the load on the system by

moving tasks and users to other

servers that aren’t involved in the

migration. For more information,

see Exchange 2007: Monitoring

Mailbox Servers and

Understanding Exchange

Performance.

When migrating from an on-

premises Exchange organization

where there are multiple mailbox

servers and multiple databases,

we recommend that you create a

migration user list that is evenly

distributed across multiple

mailbox servers and databases.

Based on individual server

performance, the list can be

further fine-tuned to maximize

throughput. For example, if

server A has 50 percent more

resource availability than server

B, it’s reasonable to have 50

percent more users from server A

in the same migration batch.

Similar practices can be applied

to other source systems.

http://technet.microsoft.com/en-us/library/bb201689(EXCHG.80).aspx

http://technet.microsoft.com/en-us/library/bb201689(EXCHG.80).aspx

http://technet.microsoft.com/en-us/library/dd351192.aspx




36

Checklist Description Best practices

Perform migrations when servers

have maximum resource

availability, such as after hours or

on weekends and holidays.

Back-end tasks Other back-end tasks that are

running during migration time.

Because it’s a best practice to

perform migration after business

hours, it’s common that migrations

conflict with other maintenance

tasks running on your on-premises

servers, such as data backup.

Review other system tasks that

might be running during

migration. We recommend that

you perform data migration

when no other resource-

intensive tasks are running.

Note: For customers using on-

premises Microsoft Exchange, the

common back-end tasks are backup

solutions and Exchange store

maintenance.

Factor 2: Migration server

Native Office 365 hybrid migration is a cloud-initiated pull/push data migration and an Exchange 2010

coexistence server acts as the migration server. If a low-scale virtual machine is used as the coexistence server,

the result will be poor migration performance.

Best practice

In addition to applying best practices previously described in the Data Source Server section, consider the

following to improve migration performance:

Use powerful server-class physical machines instead of virtual machines for the Exchange 2010 or Exchange

2013 coexistence servers. An example is the following:

o CPU: Intel® Xeon® CPU E5520 @ 2.27 GHz 2.26 GHz (two processors)

o Memory: 24 GB

o Disks: Eight at 146 GB per disk. RAID 5 configuration = 960 GB total raw space

Use multiple coexistence servers that are behind your on-premises network load balancer.

Configure MRS Proxy with a concurrency of 100.

Note

Disk performance is more important than available space for migration performance.

Factor 3: Migration engine

Native Office 365 hybrid migration uses native Office 365 tools that are subject to Office 365 resource health-

based throttling.

http://technet.microsoft.com/en-us/library/aa996226(EXCHG.65).aspx

http://technet.microsoft.com/en-us/library/aa996226(EXCHG.65).aspx



37

Exchange 2003 vs. Exchange 2007 SP2 and Exchange 2010

There is a key difference for the end-user experience when the migration is from Exchange 2003. Unlike

Exchange 2007 SP2 and Exchange 2010, Exchange 2003 end users cannot access their mailboxes when their data

is being migrated; therefore, Exchange 2003 customers are usually more concerned about when to schedule

migrations and the time required to migrate – especially when migration performance is low because of large

mailbox sizes or a slow network. Exchange 2003 migration is also very sensitive to interruptions. If a service

incident occurs during the migration of an Exchange 2003 mailbox, the restart of intermediate servers involved

in the migration may be required. Migrations involving Exchange 2007 SP2 and Exchange 2010 tend to be more

resilient when service interruptions occur.

Best practice

Some customers choose to do two-hop migrations for large and sensitive Exchange 2003 mailboxes:

First hop Migrate mailboxes from Exchange 2003 to an Exchange 2010 server which is usually the

hybrid coexistence server. The first hop is an offline move, but it’s usually a very fast migration over a

local network.

Second hop Migrate mailboxes from Exchange 2010 to Office 365.

The second hop is an online move which provides a better user experience and fault tolerance. This two-

hop approach requires an Exchange 2010 license for the temporary on-premises Exchange 2010 user

mailbox.

Mailbox Replication Service Proxy (MRS Proxy)

MRS Proxy is the on-premises migration feature that works with the Mailbox Replication Service running within

Office 365 Dedicated. For more information, see Understanding Move Requests.

Best practice

The maximum number of MRS Proxy connections for the on-premises Exchange 2010 SP2 can be configured

using the following remote Windows PowerShell command:

Set-WebServicesVirtualDirectory -Identity "EWS (Default Web Site)" -MRSMaxConnections <number

between 0 and unlimited; default is 100>

Note

For most customer migrations, it’s unnecessary to change the default MRSMaxConnections value. If you

need to protect the source server from being overwhelmed by the migration load, customers can reduce

the number of connections. This setting is per MRS Proxy server. If you have two MRS Proxy servers, each

set to 10 connections, you will get 20 (2 x 10) total MRS Proxy connections. For more information about

configuring the MRS Proxy service in your on-premises Exchange 2010 organization, see Start the MRS

Proxy Service on a Remote Client Access Server.

Factor 4: Network

Network utilization at the time of the migration is a factor that dictates actual migration performance. Testing

network performance for hybrid migrations can be done by performing multiple test mailbox migrations.


http://technet.microsoft.com/en-us/library/ee732395.aspx

http://technet.microsoft.com/en-us/library/ee732395.aspx



38

Factor 5: Office 365 service processes

Office 365 resource health-based throttling can affect the performance of migrations. The throttling impact is

based upon the priority of the migration type being executed as described in the following:

Onboarding move requests New customer migrations are considered onboarding move requests. These

requests have regular priority.

Data center internal move requests These are mailbox move requests initiated by data center operation

teams. These requests have a lower priority because the end-user experience isn’t affected if there’s a delay

in the move request.

When viewing migration status, the following provides an indication of migration processing performance

within Office 365:

Queued move requests This status specifies that the move has been queued and is waiting to be picked

up by the Microsoft Exchange Mailbox Replication service. For Exchange 2003 move requests, users can still

access their mailboxes at this stage.

Two factors influence which request will be picked up by Mailbox Replication service:

Priority Queued move requests with a higher priority are picked up before lower-priority move

requests. This helps ensure that customer-migration move requests always get processed before

data center internal move requests.

Position in the queue If move requests have the same priority, the earlier the request gets into

the queue, the earlier it will be picked up by the Mailbox Replication service. Since you may have

other self-service administrators performing mailbox migrations at the same time, it is normal for

new move requests to remain in the queue before they are processed.

Often, the time that mailbox requests wait in the queue before being processed isn’t considered during

migration planning. This results in customers not being allocated enough time to complete all planned

migrations.

In-progress move requests This status specifies that the move is still in progress. If this is an online

mailbox move, the user will still be able to access the mailbox. For offline mailbox moves, the user's mailbox

will be unavailable.

After the mailbox move request has a status of In Progress, the priority no longer matters and a new move

request won’t be processed until an existing In Progress move request is completed even if the new move

request has a higher priority.

For general information about getting status information for move requests, see View Move Request Properties.




39

Best practices

Planning

As previously mentioned, because Exchange 2003 users lose access during a hybrid migration, Exchange

2003 customers are usually more concerned about when to schedule migrations and how long they will take.

When planning how many mailboxes to migrate during a specific time period, calculate the amount of time

the move request waits in the queue by using the following formula:

(total number of mailboxes to migrate) = ((total time) – (average queue time)) * (migration throughput)

In the above, migration throughput equals the total number of mailboxes that can be migrated per hour.

For example, assume you have a six-hour window to migrate mailboxes. If the average queue time is one

hour and you have a migration throughput of 100 mailboxes per hour, you can migrate 500 mailboxes in the

six-hour time frame: 500 = (6 – 1) * 100. Start the migration sooner than initially planned to mitigate time in

the queue. When mailboxes are queued, Exchange 2003 users can still access their mailboxes.

Determine queue time

The queue time is always changing because Microsoft does not manage migration scheduling. To determine

the potential queue time, you can try to schedule a test move several hours before the actual migration

starts. Then, based on the observed amount of time the request is in the queue, you can better estimate

when to start the migration and how many mailboxes can be moved in a specific period of time.

For example, if a test migration was completed four hours before the start of a planned migration and the

queue time was observed to be about one hour, then you should consider starting the migration one hour

earlier than originally planned to ensure there is enough time to complete all migrations.



40

Appendix B – Using a CSV File for Mailbox Migration In addition to using the mailbox selection function of the EAC to prepare and execute a batch migration, you can use a

CSV file to migrate a large number of user mailboxes. You can specify a CSV file to create a migration batch to on-

board or off-board users when you use the Exchange Admin Center (EAC) or the New-MigrationBatch cmdlet in

remote Windows PowerShell. Multiple migration batches can be prepared for the remote move migration process.

Notes

1. When using the EAC selection function or a CSV file, the maximum number of mailboxes per migration

batch is 2000.

2. Both on-boarding and off-boarding remote move migrations are initiated from your Exchange Online

organization.

3. If the off-boarding source or on-boarding target is the multi-tenant version of Exchange Online, the EAC

migration tool must be launched from within the multi-tenant environment and the required Target

Endpoint must be indicated.

Supported attributes for CSV files for bulk moves or migrations

The first row (header row) of a CSV file used for migrating users contains the names of the attributes specified on

the rows that follow. Each attribute name is separated by a comma. Each row under the header row represents an

individual user and the information required for the migration of the user’s mailbox. The attributes in each individual

user row must be in the same order as the attribute names in the header row. Each attribute value is separated by a

comma. If the attribute value for a particular record is null, do not type anything for that attribute; however, make

sure that you include the comma to separate the null value from the next attribute.

Attribute values in the CSV file override the value of the corresponding parameter used when creating a migration

batch using the EAC or the remote Windows PowerShell. For more information and examples, see the section

Attribute values in the CSV file override the values for the migration batch below.

Tip:

You can use any text editor to create the CSV file. Using an application like Microsoft Excel will make it

easier to import data and configure and organize the CSV file. Be sure to save CSV files as a .csv or .txt file.

The following sections describe the supported attributes for the header row of a CSV file for each migration type.

Each section includes a table that lists each supported attribute, whether it’s required, an example of a value to use

for the attribute, and a description.



41

Note

In the following sections, source environment denotes the current location of a user mailbox or a database.

Target environment denotes the location that the mailbox will be migrated to or the database that the

mailbox will be moved to.

On-boarding remote move migrations in a hybrid deployment

As described above in Mailbox Migration to/from Exchange Online Dedicated, you can move mailboxes from an

on-premises Exchange organization to Exchange Online Dedicated via a hybrid deployment. When on-boarding

mailboxes, the migration batch is created and executed from within the Exchange Online organization. The

following table describes the supported attributes for a CSV file for on-boarding remote move migrations.

Attribute Required or

optional

Accepted values Description

EmailAddress Required SMTP address

for the user

Specifies the email address for the mail-

enabled user in the Exchange Online

organization that corresponds to the on-

premises user mailbox that will be

migrated.

BadItemLimit1 Optional Unlimited or a

non-negative

integer from 0

(the default) to a

maximum value

of 2147483647

Specifies the number of bad items to

skip if the migration service encounters a

corrupted item in the mailbox. If you

include this attribute in the CSV file, it

will override the default value or the

value you specify if you include the

BadItemLimit parameter when creating

the migration batch using the EAC or

PowerShell.

Tip:

We recommend that you use the

default value of 0 and only

increase the bad item limit for a

particular user if the move or

migration for that user fails.



42

Attribute Required or

optional


LargeItemLimit1 Optional Unlimited or a

non-negative

integer from 0

(the default) to a

maximum value.

Specifies the number of large items in

the user’s mailbox that will be skipped.

When the number of large items exceeds

this value, the migration for the mailbox

fails. The default value is 0, which means

that the migration fails if the mailbox

contains any large items. When on-

boarding mailboxes to Exchange Online,

items up to the maximum send/receive

message size for your environment are

migrated.

1The BadItemLimit and LargeItemLimit values can be set on a per user basis in the .csv file.

Off-boarding remote move migrations in a hybrid deployment

As described above in Mailbox Migration to/from Exchange Online Dedicated, you can move mailboxes from

Exchange Online Dedicated to an on-premises Exchange organization via a hybrid deployment. When off-boarding

mailboxes, a CSV file can be created for the migration batch. The following table describes the supported attributes

for a CSV file used for off-boarding migrations and for cross-forest enterprise remote moves.

Attribute Required

or optional


EmailAddress Required SMTP address

for the user

For cross-forest enterprise

moves, this specifies the

mailbox or mail-enabled

user in the source forest.

For off-boarding remote

move migrations, it specifies

the Exchange Online

mailbox.



43

Attribute Required

or optional


TargetDatabase Required for off-

boarding remote

move migrations

that are initiated

from the source

forest.

Alternatively, this

attribute can be

specified when

creating the

migration batch

in the EAC or

using the Shell.

Database name Specifies the mailbox

database in the target forest

that the user’s primary


You can specify a different

database in the different

rows of the CSV file, which

lets you move mailboxes in

the same migration batch to

different databases.

TargetArchiveDatabase Optional Database name This attribute is only

supported for off-boarding

remote move migrations.

Specifies the mailbox

database in the target forest

that the user’s archive


You can specify a different

database in the different

rows of the CSV file which

will let you move archive

mailboxes in the same

migration batch to different

databases.



44

Attribute Required

or optional


BadItemLimit Optional Unlimited or

a non-negative

integer from 0

(the default) to

a maximum

value of

2147483647

Specifies the number of bad

items to skip if the migration

service encounters a

corrupted item in the

mailbox. If you include this

attribute in the CSV file, it

will override the default

value or the value you

specify if you include the

BadItemLimit parameter

when creating the migration

batch using the EAC or the

Shell.

Tip:

We recommend that

you use the default

value of 0 and only

increase the bad item

limit for a particular

user if the move or

migration for that

user fails.



45

Attribute Required

or optional


LargeItemLimit Optional Unlimited or

a non-negative

integer from 0

(the default) to

a maximum

value.

Specifies the number of

large items in the user’s

mailbox that will be skipped.

When the number of large

items exceeds this value, the

migration for the mailbox

fails. The default value is 0,

which means that the

migration fails if the mailbox

contains any large items.

When off-boarding

mailboxes to Exchange on-

premises, a large item is

defined by the transport

limits. To determine the

transport limit,, use remote

Windows PowerShell to

execute the following:

Get-TransportConfig |

Format-List

MaxReceiveSize

Attribute values in the CSV file override the values for the migration batch

Attribute values in the CSV file override the value of the corresponding parameter when that same parameter is

used when creating a migration batch with the EAC or the Shell. If you want the migration batch value to be

applied to a user, you would leave that cell blank in the CSV file. This lets you mix and match certain attribute

values for selected users in one migration batch. The example below shows how a batch can be created using a

CSV file for a cross-forest enterprise migration to move the primary and archive mailboxes of users to a target

forest:

New-MigrationBatch -Name CrossForestBatch1 -SourceEndpoint ForestEndpoint1 -TargetDeliveryDomain

forest2.contoso.com -TargetDatabases @(EXCH-MBX-02,EXCH-MBX-03) -TargetArchiveDatabases @(EXCH-MBX-

A02,EXCH-MBX-A03) -CSVData

([System.IO.File]::ReadAllBytes("C:\Users\Administrator\Desktop\CrossForestBatch1.csv")) -AutoStart



46

Note

Because the default action is the move of the primary and archive mailboxes, you don’t have to explicitly

specify this action in the Shell command.

A portion of the CrossForestBatch1.csv file for this migration batch looks like the following:

Off-boarding Example CSV

EmailAddress,TargetDatabase,TargetArchiveDatabase

[email protected],EXCH-MBX-01,EXCH-MBX-A01

[email protected],,

[email protected],EXCH-MBX-01,

...

Because the values in the CSV file override the values for the migration batch, the primary and archive mailboxes

for user1 are moved to EXCH-MBX-01 and EXCH-MBX-A01, respectively, in the target forest. The primary and

archive mailboxes for user2 are moved to either EXCH-MBX-02 or EXCH-MBX-03. The primary mailbox for user3

is moved to EXCH-MBX-01 and the archive mailbox is moved to either EXCH-MBX-A02 or EXCH-MBX-A03.

On-boarding Example CSV

New-MigrationBatch -Name RemoteOnboarding1 -SourceEndpoint ForestEndpoint1 -TargetDeliveryDomain

forest2.contoso.com -CSVData

([System.IO.File]::ReadAllBytes("C:\Users\Administrator\Desktop\CrossForestBatch1.csv")) -AutoStart

EmailAddress,BadItemLimit,LargeItemLimit

[email protected],200,200

[email protected],,

[email protected],50,

...

Because the values in the CSV file override the values for the migration batch, the BadItemLimit and

LargeItemLimit for user 1 are different from other users and will not take the default values specified for the

batch defaults. For user2, we are accepting the default batch values for BadItemLimit and LargeItemLimit. For

User 3, we only need to override the BadItemLimit defaults for the batch.

The default value for BadItemLimit and LargeItemLimit is 0. For all migration scenarios, we recommend that you

accept the default value and only change the BadItemLimit parameter value if the move or migration fails for a

particular mailbox.



47

Appendix C – Mailbox migration in a multi-region environment Within an Exchange Online Dedicated environment, a customer administrator is able to perform the self-service

migration of a valid mailbox type between Office 365 Dedicated datacenters located in other geographic regions.

Mailbox types that can be moved are standard user mailboxes as well as resource, shared, and inactive mailboxes.

Notes

1. An inactive mailbox must be temporarily assigned a user mailbox plan before it can be

migrated. Following the migration, the mailbox can be converted back to an inactive type.

See the MAILBOX PROVISIONING ATTRIBUTE section of the Office 365 Dedicated and

ITAR-support Plans Provisioning Tools Handbook for additional information regarding how

to set the characteristics of a mailbox.

2. A public folder mailbox must be migrated by Microsoft Online Services using the

Configuration Request process. Contact your Microsoft Service Delivery Manager for

assistance.

Preparation

Prior to invoking the mailbox migration, the RegionCode for the source mailbox must be set to the value that

represents the destination region. The value is set by executing the Set-Mailbox cmdlet using remote Windows

PowerShell as shown in the syntax example below.

Set-Mailbox –Identity <MailboxIdParameter> -MailboxProvisioningConstraint "{Region -eq '<RegionCode>'}"

Identity parameter specifies the mailbox using a format as described in the Set-Mailbox cmdlet description

(see Parameters section of description).

MailboxProvisioningConstraint parameter is available only within the Exchange Online Dedicated

(parameter is not shown within Microsoft TechNet description). Valid RegionCode values are the following:

O365D Datacenter Mailbox Provisioning Constraint

RegionCode Value

Asia-Pacific APC

Europe EUR

North America NAM

Important

http://technet.microsoft.com/en-us/library/bb123981%28v=exchg.150%29.aspx



48

1. Within Exchange Online Dedicated, a mailbox is initially provisioned using the mailbox

provisioning attribute. The provisioning attribute is an Active Directory extension attribute (also

referred to as an Exchange CustomAttribute) associated with an AD user object. The provisioning

attribute contains a flag that sets the initial geographic region value (REG=<value>) for the mailbox.

The value options for REG= are not the same as the value options for the RegionCode used in the

MailboxProvisioningConstraint value.

2. When the Set-Mailbox cmdlet is used to set the region code for the mailbox, the

MailboxProvisioningConstraint value becomes the authoritative value within Exchange Online

Dedicated that identifies the regional location of the mailbox. Following the step to set the

MailboxProvisioningConstraint value, recommended is the removal of the REG= value in the

mailbox provisioning attribute.

For more information describing the use of the mailbox provisioning attribute, see the MAILBOX

PROVISIONING ATTRIBUTE section of the Office 365 Dedicated and ITAR-support Plans Provisioning Tools

Handbook.

Execution

In Exchange Online Dedicated, the load balancing service on every mailbox server manages the execution of the

migration. Within 24 hours of the MailboxProvisioningConstraint value being set, the move will be scheduled

by the service. The actual time required to complete the migration depends upon the mailbox type and size. Most

moves typically are completed by the migration service within 24 hours of being scheduled. The mailbox will be

moved onto a database that matches the MailboxProvisioningConstraint value.

Note

The execution of the migration will be blocked if a move request is pending for the mailbox.

Use the Remove-MoveRequest cmdlet to delete the move pending move request.

Verification

To validate the completion of the migration, the following can be executed using remote Windows PowerShell:

Get-Mailbox <Identity> |fl database,mailboxprovisioningconstraint

Identity parameter specifies the mailbox using a format as described in the Get-Mailbox cmdlet description

(see Parameters section of description).

An example of the data returned is the following:

http://technet.microsoft.com/en-us/library/bb123685%28v=exchg.150%29.aspx



49

Database : NAMSR99DG001-db013

MailboxProvisioningConstraint : {Region -eq 'EUR'}

Example of how to audit mailboxes by region (example illustrates search for all mailboxes located in the European

region):

Get-Mailbox -ResultSize Unlimited | ? {$_.MailboxProvisioningConstraint -eq "Region -eq 'EUR'"}

Troubleshooting

The migration service will not complete the mailbox move if any of the following conditions exist:

Error Corrective Action

The legacy region code parsed from

the customAttribute

"<value_strings>" is invalid

Correct the REG value in the mailbox provisioning attribute for

the object to be one of the following:

REG=AP;

REG=EU;

REG=NA;

Incorrect

MailboxProvisioningConstraint

value set on the mailbox

Correct the MailboxProvisioningConstraint value to be one

of the following:

"{Region -eq 'APC'}"

"{Region -eq 'EUR'}"

"{Region -eq 'NAM'}"

There is no database with

MailboxProvisioningAttributes

satisfying the

MailboxProvisioningConstraintEntry:

'Region –eq 'value’ ‘

Migration service is unable to verify existence of a database in

the destination region; contact Microsoft Online Service Support

if the database should be available or adjust the Region value to

a valid regional database

Move request exists for the mailbox Use Remove-MoveRequest to delete the move pending move

request

self-service mailbox migration in exchange online dedicated · client access servers (if configured...

Documents