While migrating from Exchange on-prem to O365 you might receive the following error: “The call to https://mail.domain.com/EWS/mrsproxy.svc’ failed”

After extending your Exchange Organization to Office 365, the next step is to enable the migration end point to move mailboxes from your Exchange Organization to Office 365. When creating the migration end point from Office 365 the following error is returned:

“The call to https://mail.domain.com/EWS/mrsproxy.svc’ failed”

The error returned in the GUI is limited on what the actual issue is. To understand why the creation of the migration end point is failing, open PowerShell and connect to Exchange Online (link). Within the PowerShell window run this command:

Get-MoveRequestStatistics -Identity "domain\user" | fl

The command will return the following error message:

“The HTTP request is unauthorized with client authentication scheme ‘Negotiate’”

On the on premise Exchange Server 2013, open the Event Viewer and navigate to the Security logs. Look for the following event:

Migration Account that failed:
Security ID: NULL SID
Account Name: migration account
Account Domain: domain.com
Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xC000006D
Sub Status: 0xC000006A

The error code 0xC000006D translates to “The attempted logon is invalid. This is either due to a bad username or authentication information.”

More important is the Sub Status error code, 0xC000006A, which translates to “When trying to update a password, this return status indicates that the value provided as the current password is not correct.”

Now we are getting somewhere, we know that the account is good and the password is good too. With much research it turns out from the Cloud side O365 sends NTLMv1 requests and the Exchange Server is refusing these requests.

To resolve this issue you will need to go to the Local Security Policy on the Exchange Server and then to “Network security: Lan Manager Authentication level” and set it to “Send NTLMv2 responses only”. Ours was not set, flipping the bit resolved the issue and mailbox migration proceeded without any more hiccups.