Move mailbox from Exchange 2010 On Premise to Office 365

Screenshots below outlines the process of moving a mailbox from on-premise Exchange 2010 enviroment to Office 365.

Assumptions:

• Primary SMTP Domain: CONTOSO.COM
• Federated Service Domain: SERVICE.CONTOSO.COM
• External URL for Co-exist Exchange 2010 server: OWA.CONTOSO.COM

Prerequisites:

• Rich Co-exist has already been established between On-prem Exchange and Office 365 (refer to Exchange Hybrid Deployment Configuration Tips: Sharing Free/Busy Information and Exchange Server Deployment Assistant on how to) 
• Mailbox Replication Proxy Service has been enabled on the co-exist Exchange 2010 server.

Steps:

1. From EMC On-Premise, go to Recipient Configuration -> Mailbox, highlight the mailbox you are going to move, click New Remote Move Request from the Action pane

2. Choose Office 365 as the target forest; specify external URL of your co-exist Exchange 2010 server with an account that has adequate permission to the on-premise Exchange environment

3. Enter the federated service domain as the Target Delivery Domain

4. After the remote move request has been generated successfully, go to EMC Cloud -> Recipient Configuration- > Move Request to verify the status of the move request. You can also run Get-MoveRequest | Get-MoveRequestStatistics from a remote powershell session that connects to Office 365 to verify the status.

5. The move request has completed successfully.

6.  As a result, user4 now is showing as the Contact in on-premise Exchange

    And a mailbox in Office 365.

Exchange 2010 Federated Delegation with TMG

During a recent rich co-exist deploymnet between on-premise Exchange 2010 and Office 365,  I noticed therer is a problem establishing organizational relationship from Office 365 to on-premise Exchange coexist server when on-premise Autodiscover is published by a TMG server. Exchange 2010 federation uses SAML tokens—not user accounts—to authenticate against IIS for EWS calls. TMG doesn’t know how to validate SAML tokens, so the incoming requests can’t be authenticated and passed on to the Exchange Server 2010 coexist server. Every time a cloud user tries to view free/busy information of an on-premise user, there is a log in the TMG server indicating "Access Denied"

The end result is that we couldn’t get a proper sharing relationship setup and you can’t federate calendar data.

When we knew what the problem was, fixing it involved modifying the OWA and ECP virtual directories on all of our Exchange Server 2010 CAS servers to perform FBA, then modifying the Web listener on our TMG Server to disable pre-authentication. Finally, we needed to modify the authentication settings for each of the TMG publishing rules for ActiveSync, Outlook Anywhere, and OWA to set them to No Delegation, But Client May Authenticate Directly, and to revise the Users settings from All Authenticated Users to All Users. Revising the Users settings is important; without this, ISA won’t pass any connections on to the CA servers. You may also need to verify that the authentication settings of your other Exchange virtual directories are valid; many organizations will allow basic authentication between TMG and their CAS servers, but require NTLM or Windows Integrated from external clients to TMG.

If you’re using multiple Web listeners to publish Exchange 2010, then your step may be different. The federated delegation feature requires direct access to the EWS vdir on your CAS servers, and EWS is typically published on TMG as part of the Outlook Anywhere rules. If you publish those using a separate Web listener—which will require a separate IP address, FQDN, and SSL certificate—you can simply disable pre-authentication for that Web listener, but still allow it on your OWA, ECP, and EAS directories.

Calendar sharing and TMG FBA pre-authentication are both wonderful features, but at this point they are not compatible.