Migration error - can't connect to on-premises Exchange server

This question is answered This question is answered

I am having problems with migrating. 

Background:

Federated domain SSO & DirSync activated and working

Test Users are assigned licenses

 

I currently have Exchange 2007 SP1 in house and are wanting to migrate a few test users to Office 365.  When we go to migrate, we input all the correct information (as verified by the Remote Connectivity Analyzer outlook anywhere test) but we receive the following error message:  

 

Has been tried with multiple different accounts, including a domain admin (with full permission to the mailboxes to be migrated).  I can see in the security log of my on-premise exchange server that the account is being successfully authenticated through the RPC proxy.

 

Could this be something with the domain being federated and the RPC proxy having an address in that domain?

 

Steps to reproduce this error:

From Exchange Online

 -->Users&Groups

 -->Email Migration

 -->New

 -->Exchange 2003 and later versions - Manually specify connection settings

 Enter a Domain Admin username and password

 internal exchange server address: Address of my internal on-premise ex2007 server (has a .local address if that helps)

 rpc proxy server: external address of

 Authentication: NTLM

 Number: any

 -->NEXT

 ERROR in picture above

Verified Answer
  • This may sound weird... I had the same error and found that if I enable basic authentication for the RPC virtual directory in IIS then error disappers. Weird because logs still tells me it is using NTLM and not Basic... Also weird because Exchange change it back and disable basic authentication after approximately 5 min but then the migration has started and will continue.

All Replies
  • Hi

    You said you’ve used the Exchange Remote Connectivity Analyzer at https://www.testexchangeconnectivity.com to test the connection to the on-premises server by using the same credentials that were used to migrate the user.

    I’d like to confirm that if you tested by using both the Outlook Anywhere (RPC over HTTP) option and the Outlook Autodiscover option.

    • If so, I suggest that you try to connect to the mailbox by using a supported version of Outlook or by using a supported IMAP client. If you cannot connect to the account by using the protocol that you selected in the Exchange Control Panel Migration Wizard, there is most likely a configuration issue or a permissions issue in the environment that you selected in the migration wizard.
    • If not, please have these two options selected and run the test. The returned information can help to determine where the connection may be failing.

    Let’s move forward after collecting the information mentioned above.

    Regards,

    Daizy

  • Yes, my test was with the Exchange Remote Connectivity Analyzer and I did test using Outlook Anywhere (RPC over HTTP).  And, I have around 250 users using this exchange server and I have verified, again, that it is working properly with OA.

    Why would the autodiscover settings matter?  As documented in my listed steps, I am not relying on autodiscover for migration (using manual).  

     

    Here's the (edited) Exchange Remote Connectivity Analyzer results when using OA test:

  • Hello,

    Are you in RichCoexistence, or the basic Simple Co-Existence? Please confirm.

  • Simple Co-Existence

  • This may sound weird... I had the same error and found that if I enable basic authentication for the RPC virtual directory in IIS then error disappers. Weird because logs still tells me it is using NTLM and not Basic... Also weird because Exchange change it back and disable basic authentication after approximately 5 min but then the migration has started and will continue.

  • This is what I ended up doing last week after looking at IIS logs.  It is definitely bizzare!  I added basic authentication as part of the Outlook Anywhere  settings using powershell.  This way, the Exchane SA service will not reset the authentications settings.