Welcome to the Hybrid migration Troubleshooter

NOTE: This troubleshooter will not help you with troubleshooting Staged, Cutover, or IMAP migrations.

Were you able to initiate the mailbox move?

We need to determine if the mailbox move was successfully initiated, which means you were able to either go through the Exchange Administration Center (EAC), Exchange Management Console (EMC), or Remote PowerShell to begin the move request and you had no issues getting the request started.

Welcome to the Hybrid migration Troubleshooter

NOTE: This troubleshooter will not help you with troubleshooting Staged, Cutover, or IMAP migrations.

Were you able to initiate the mailbox move?

We need to determine if the mailbox move was successfully initiated, which means you were able to either go through the Exchange Administration Center (EAC), Exchange Management Console (EMC), or Remote PowerShell to begin the move request and you had no issues getting the request started.

I could not initiate a move request (more common)

I was able to initiate the move request

I am not certain if the move request was initiated

0

Were you able to initiate the mailbox move?

We need to determine if the mailbox move was successfully initiated, which means you were able to either go through the Exchange Administration Center (EAC), Exchange Management Console (EMC), or Remote PowerShell to begin the move request and you had no issues getting the request started.

I could not initiate a move request (more common)

I was able to initiate the move request

I am not certain if the move request was initiated

0

Try to use the Exchange Administration Center (EAC) to perform the move

Mailbox moves are more likely to succeed when they are initiated from the EAC in Exchange Online. Please connect to the EAC in Exchange Online and see if you can initiate the move from there.

On the Select a migration type page, select Remote move migration as the migration type for a hybrid mailbox move.

On the Select the users page, select the mailboxes you want to move to the cloud.

On the Enter on-premises account credentials page.

Enter the on-premises Database Name, this can be retrieve by running Get-MailboxDatabase from EMS.Important: provide your on-premises administrator credentials in the domain\user format.

On the Confirm the migration endpoint page, ensure that the on-premises endpoint shown is the CAS with MRS Proxy enabled.

Enter a name for the migration batch and initiate the move.

This resolved my issues

My move still failed to initiate

0

Ensure that the migration endpoint is enabled and that the proper Authentication options are in place

When you are moving a mailbox to or from the cloud we make a connection to the on-premises environment to the MRSProxy endpoint. Please verify that the MRSProxy endpoint and the WSSecurity authentication type are enabled.

Open the Exchange Management Shell on the Exchange 2010 or 2013 hybrid server.

Check to see if the MRSProxyEnabled and WSSecurityAuthentication are both set to True. To do this, run the following cmdlet, The word Server in the below cmdlets should reflect the names of the external facing Exchange servers:Get-WebServicesVirtualDirectory -Identity "Server\EWS (default Web site)" |fl Server,MRSProxyEnabled,WSSecurityAuthentication

If either is false run the following to enable the MRSProxy and set the authentication required to perform the move. To do this, run the following cmdlet:Set-WebServicesVirtualDirectory -Identity "Server\EWS (default Web site)" –MRSProxyEnabled $true – WSSecurityAuthentication $True

Note: These settings should be configured on all of the external facing Exchange servers.

This resolved my issue

I have verified that MRSProxy and Authentication settings, what next?

0

Do you have your Firewall and Intrusion Detection System (IDS) properly configured

You need to ensure that you have your firewall configured to allow certain EWS and Autodiscover endpoints to come through to the Exchange servers without being authenticated at a perimeter device. Additionally, you need to ensure that the migration requests are not treated like a denial of service attack.

Firewall endpoint/pre-authentication settings

The following are the instructions for how to properly publish EWS and Autodiscover via TMG, but you can apply this logic to your own device. This link will provide explicit steps for TMG, but at a high level you need to do the following:

Create a new publishing rule (often using the same listener that is already in place) that does not require pre-authentication.

Ensure that the rule applies to any traffic that comes over the following paths.

/ews/mrsproxy.svc

/ews/exchange.asmx/wssecurity

/autodiscover/autodiscover.svc/wssecurity

/autodiscover/autodiscover.svc

Ensure that this new rule is higher in priority than any existing Exchange Related Firewall rules.

IDS settings

Hybrid Migrations can sometimes be treated like a denial of service attack by certain devices. The following logic can be applied to any intrusion detection system, but it was written for TMG specifically.

Open the Forefront TMG management console, and then in the tree click Intrusion Prevention System.

Click the IP Exceptions tab, and then type the IP addresses that the Office 365 environment uses to connect during the mailbox move operation. To view a list of the IP address ranges and URLs that are used by Exchange Online in Office 365, visit the following Microsoft website:http://help.outlook.com/en-us/140/gg263350.aspx

Click the Flood Mitigation tab, and then, next to Maximum HTTP Requests per minute per IP address, click Edit. In the Custom limit box, type a number to increase the limit. Note: The custom limit applies to IP addresses that are listed on the IP Exceptions tab. Increase only the custom limit. In the following example screen shot, the custom limit is set to 6,000. Depending on the number of mailboxes that are being moved, this number may not be sufficient. If you still receive the error message, increase the custom limit.

This resolved my issue

My TMG is properly configured or I do not have TMG, what next?

0

Remove existing move requests

Having a move request (even a successful one) could prevent a mailbox move from taking place. Connect PowerShell to Exchange Online and verify that there is no move request pending for the user in question. If there is a stale move request you will need to remove it. The following steps outline how to determine if there is an existing move request and remove that request if it exists.

Run the following command: Get-MoveRequest -Identity 'tony@contoso.com'.

If there is a move request that is completed or failed run: Remove-MoveRequest -Identity 'tony@contoso.com'.

This resolved my issue

I have confirmed that there is no stale move requests, what next?

0

Verify that the appropriate accepted domains are in place

Often when moving a mailbox to Exchange online it will fail because some of the accepted domains are missing in the service. Please verify if all of the email domains assigned to this user are added and verified in the service.

Open Exchange Management Shell.

Run: (Get-Mailbox Tony).EmailAddresses.

Take note of all of the email addresses that follow smtp: and write the domain names down.For instance, if the results include SMTP:tony@contoso.com, smtp:Tony@foo.com you would need to write down Contoso.com and Foo.com

Run: Get-AcceptedDomain and ensure that the results include the domain(s) noted in step 3 above.

If any of the domains are missing you should add and verify the domain in the portal. Alternatively, you can license the user before you move the mailbox. Usually we use the option of licensing a user when one of the domains stamped on the mailbox is a .local or non-routable domain. Non-routable addresses cannot be added to the service therefore they will not be stamped on the user in Exchange Online.

This resolved my issue

I have verified that the accepted domains are in place, what next?

0

Ensure that IIS is properly configured to accept migration traffic

In order for IIS to properly respond to a migration request we need to ensure that the Handler Mappings are in place.Please verify that the EWS and Autodiscover handler mapping are in place.

Expand the Server name, then Sites, then Default Web Site, then left click on EWS.

In the middle pane select the Handler Mappings option.

Look to see if there is a mapping with the following:

Name= svc-Integrated

Path= *svc

State= Enabled

Repeat steps 1 through 4 but this time check the autodiscover virtual directory.

If any of the values are missing perform the remediation steps 7 and 8.

On the Exchange 2010/2013 external facing server(s), open a Command Prompt window, and then move to the following folder:C:\Windows\Microsoft.Net\Framework\v3.0\Windows Communication Foundation\

Type the following command, and then press Enter:ServiceModelReg.exe –r

This resolved my issue

My IIS has the proper handler mappings in place, what next?

0

Ensure that the required attribute synchronized properly (this is not a common problem)

In order for a mailbox move to succeed you need to have a user account in both on-premises and Exchange Online that have a matching mailbox guid. Please verify that the mailbox guid is in place and matches

Ensure you stamp the newly created account with the proper Exchange GUID retrieved from step “2”, this will be done in the On-Premises EMS:Set-MailUser Testuser –ExchangeGuid xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

This resolved my issue

My move request still failed to initiate

0

Run the migration from PowerShell

Initiating the migration from PowerShell often yields a more actionable error message. The following steps walk you through the process of moving a mailbox from on-premises to Exchange Online via PowerShell

Then create a variable to store your on-premises admin credentials. The credentials should be stored in the format of contoso\administrator and not administrator@contoso.com.$onpremCred = Get-Credential

Then run a cmdlet similar to the following, where ‘User’ is the display name for the account you want to move, ‘Webmail.consoto.com’ is the endpoint that has MRSProxy enabled on-premises, and ‘contoso.mail.onmicrosoft.com’ is the routing domain used in Exchange online.New-MoveRequest –Identity ‘User’ -Remote -RemoteHostName 'webmail.contoso.com' -RemoteCredential $onpremCred -TargetDeliveryDomain 'contoso.mail.onmicrosoft.com'

This resolved my issue

My move request still failed to initiate

0

Review the status of the Move request

In order to better direct you in troubleshooting your migration issues we need to determine the current status of the move requests. In order to determine the status please perform the following steps:

The move status is Completed/Completed with warnings (link to solved page)

The move status is Suspended/Queued/In-Progress/Completion in progress/Syncing

The move request status is Failed

No move request was returned

0

Proper expectations for mailbox moves

Mailbox moves and migration batches are not handled at the same priority as client connectivity and mail flow tasks. Therefore if your server or the Microsoft datacenter is under heavy load, the Mailbox moves may be delayed. There is no reason to be alarmed if a move is in a queued state for a good deal of time since the move will more than likely be picked up relatively soon. It is best to not start troubleshooting a stalled move till there had been a long enough delay (such as 8 hours) with no progress or activity.

Migrate using Online mode

If you are migrating from an Exchange 2003 server it is better for user experience and performance if you move the mailbox first to Exchange 2010 then to Exchange Online.

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 resolved my issue

My move request is still not complete or this step does not apply

0

Network Performance factors to consider

This section describes best practices for improving network performance during migrations. The discussion is generally because the biggest impact on network performance during migration is related to third-party hardware and Internet service providers (ISPs).The Office 365 Network Analysis Tool is deployed to help analyze network-related issues prior to deploying Office 365 services:

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. Contact your ISP to confirm your allocated bandwidth and get details about restrictions, such as the total amount of data that can be transferred in a specific period of time. 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.

Hybrid Migrations can sometimes be treated like a denial of service attack by certain devices. The following logic can be applied to any intrusion detection system, but it was written for TMG specifically.

Open the Forefront TMG management console, and then in the tree click Intrusion Prevention System.

Click the IP Exceptions tab, and then type the IP addresses that the Office 365 environment uses to connect during the mailbox move operation. To view a list of the IP address ranges and URLs that are used by Exchange Online in Office 365, visit the following Microsoft website:http://help.outlook.com/en-us/140/gg263350.aspx (http://help.outlook.com/en-us/140/gg263350.aspx).

Click the Flood Mitigation tab, and then, next to Maximum HTTP Requests per minute per IP address, click Edit. In the Custom limit box, type a number to increase the limit. Note The custom limit applies to IP addresses that are listed on the IP Exceptions tab. Increase only the custom limit. In the following example screen shot, the custom limit is set to 6,000. Depending on the number of mailboxes that are being moved, this number may not be sufficient. If you still receive the error message, increase the custom limit.

This resolved my issue

My move request is still not complete or this does not apply

0

Clear failed move request

Having a move request (even a successful one) could prevent a mailbox move from taking place. Connect PowerShell to Exchange Online and verify that there is no move request pending for the user in question. If there is a stale move request you will need to remove it. The following steps outline how to determine if there is an existing move request and remove that request if it exists.

On the Select a migration type page, select Remote move migration as the migration type for a hybrid mailbox move

On the Select the users page, select the mailboxes you want to move to the cloud.

On the Enter on-premises account credentials page

Enter the on-premises Database Name, this can be retrieve by running Get-MailboxDatabase from EMSImportant: provide your on-premises administrator credentials in the domain\user format.

On the Confirm the migration endpoint page, ensure that the on-premises endpoint shown is the CAS with MRS Proxy enabled.

Enter a name for the migration batch and initiate the move.

This resolved my issue

My move still failed to initiate

0

Do you have your Firewall and Intrusion Detection System (IDS) properly configured

You need to ensure that you have your firewall configured to allow certain EWS and Autodiscover endpoints to come through to the Exchange servers without being authenticated at a perimeter device. Additionally, you need to ensure that the migration requests are not treated like a denial of service attack.

Firewall endpoint/pre-authentication settings

The following are the instructions for how to properly publish EWS and Autodiscover via TMG, but you can apply this logic to your own device. This link will provide explicit steps for TMG, but at a high level you need to do the following:

Create a new publishing rule (often using the same listener that is already in place) that does not require pre-authentication

Ensure that the rule applies to any traffic that comes over the following paths.

/ews/mrsproxy.svc

/ews/exchange.asmx/wssecurity

/autodiscover/autodiscover.svc/wssecurity

/autodiscover/autodiscover.svc

Ensure that this new rule is higher in priority than any existing Exchange Related Firewall rules

IDS settings

Hybrid Migrations can sometimes be treated like a denial of service attack by certain devices. The following logic can be applied to any intrusion detection system, but it was written for TMG specifically.

Open the Forefront TMG management console, and then in the tree click Intrusion Prevention System.

Click the IP Exceptions tab, and then type the IP addresses that the Office 365 environment uses to connect during the mailbox move operation. To view a list of the IP address ranges and URLs that are used by Exchange Online in Office 365, visit the following Microsoft website:http://help.outlook.com/en-us/140/gg263350.aspx(http://help.outlook.com/en-us/140/gg263350.aspx)

Click the Flood Mitigation tab, and then, next to Maximum HTTP Requests per minute per IP address, click Edit. In the Custom limit box, type a number to increase the limit. Note: The custom limit applies to IP addresses that are listed on the IP Exceptions tab. Increase only the custom limit. In the following example screen shot, the custom limit is set to 6,000. Depending on the number of mailboxes that are being moved, this number may not be sufficient. If you still receive the error message, increase the custom limit.

This resolved my issue

My TMG is proper configured or I do not have TMG, what next?

0

Ensure that IIS is properly configured to accept migration traffic

In order for IIS to properly respond to a migration request we need to ensure that the Handler Mappings are in place. Please verify that the EWS and Autodiscover handler mapping are in place.

Expand the Server name, then Sites, then Default Web Site, then left click on EWS.

In the middle pane select the Handler Mappings option

Look to see if there is a mapping with the following:

Name= svc-Integrated

Path= *svc

State= Enabled

Repeat steps 1 through 4 but this time check the autodiscover virtual directory

If any of the values are missing perform the remediation steps 7 and 8

On the Exchange 2010/2013 external facing server(s), open a Command Prompt window, and then move to the following folder:C:\Windows\Microsoft.Net\Framework\v3.0\Windows Communication Foundation\

Type the following command, and then press Enter:ServiceModelReg.exe –r

This resolved my issue

My IIS has the proper handler mappings in place, what next?

0

Move mailbox to a different on-premises server

Often migration issue are cause by corrupt items or mailboxes. These issues can often be resolved by moving a mailbox between two different on-premises mailbox databases. The following walks you through the process of moving a user’s mailbox from one database to another, then moving the mailbox to Exchange Online (if this is an off-boarding request, this step will need to be skipped).

This resolved my issue

My mailbox was move to a different database or this does not apply, what next?

0

Migration batches “stuck”? Try to use move requests instead

Sometimes a migration batch may become stuck at a certain stage of migration such as “Completing”. You may be able to get past this by cleaning up the old move requests.

Bypass mailbox and Item level corruption issues

Often a Mailbox move will fail due to item or mailbox level corruption. Allowing for some of the corrupt items to be skipped is often a good way to get a mailbox moved. However, there is the possibility of data loss if you use the below options

Create a variable to store your on-premises admin credentials. The credentials should be stored in the format of contoso\administrator and not administrator@contoso.com.$onpremCred = Get-Credential

Then run a cmdlet similar to the following, where ‘User’ is the display name for the account you want to move, ‘Webmail.consoto.com’ is the endpoint that has MRSProxy enabled on-premises (usually this matches the OWA endpoint), and ‘contoso.mail.onmicrosoft.com’ is the routing domain used in Exchange online. Example: The following example may result in a minor loss of data since you are allowing some items to be skipped due to corruption:New-MoveRequest –Identity ‘User’ -Remote -RemoteHostName 'webmail.contoso.com' -RemoteCredential $onpremCred -TargetDeliveryDomain 'contoso.mail.onmicrosoft.com' –BadItemLimit 40

This resolved my issue

My move request still failed to initiate (end page)

0

Congratulations! Your scenario is complete

0

The issue was not resolved

Sorry, we couldn’t resolve your issue with this guide. Please provide feedback on this walkthrough, and then use the resources below to continue troubleshooting. Visit the Office 365 Community for self-help support. Do one of the following:

Use search to find a solution to your issue.

Use the Help Center or the Troubleshooting tool that are both available from the top of every community page.

Sign in with your Office 365 admin credentials, and then post a question to the community.

Bypass mailbox and Item level corruption issues

Often a Mailbox move will fail due to item or mailbox level corruption. Allowing for some of the corrupt items to be skipped is often a good way to get a mailbox moved. However, there is the possibility of data loss if you use the below options

Create a variable to store your on-premises admin credentials. The credentials should be stored in the format of contoso\administrator and not administrator@contoso.com.$onpremCred = Get-Credential

Then run a cmdlet similar to the following, where ‘User’ is the display name for the account you want to move, ‘Webmail.consoto.com’ is the endpoint that has MRSProxy enabled on-premises (usually this matches the OWA endpoint), and ‘contoso.mail.onmicrosoft.com’ is the routing domain used in Exchange online. Example: The following example may result in a minor loss of data since you are allowing some items to be skipped due to corruption:New-MoveRequest –Identity ‘User’ -Remote -RemoteHostName 'webmail.contoso.com' -RemoteCredential $onpremCred -TargetDeliveryDomain 'contoso.mail.onmicrosoft.com' –BadItemLimit 40