Introduction
Exchange Server 2013 Cumulative Update 8 (CU8) and Exchange Server 2010 SP3 Rollup Update 9 (RU9) introduced a new feature to provide a more seamless experience for ActiveSync-enabled users who move from on-premises Exchange servers to Office 365.
This blog post explains the current situation with on-boarding Exchange ActiveSync (EAS) users as well as the new functionality offered.
EAS On-boarding
Today, when a user's mailbox moved from Exchange on-premises to Exchange Online (Office 365), Outlook and Outlook Web App (OWA) have a seamless method to redirect the user to the new mailbox location. Outlook uses Autodiscover to redirect the user, and OWA provides a link to Office 365 login.
But what about ActiveSync-enabled devices? Before the above updates are installed, after the mailbox is moved, the user’s mail stops syncing on their EAS device because the device can no longer find the current location of the mailbox. The user has to manually re-configure the device with the new URL, or delete and recreate the email account on the device.
The reason for this behavior is that when a mailbox is moved from on-premises to Office 365, the device tries to connect to the user’s mailbox’s last location before the migration, which is the on-premises server. On-premises Client Access servers did not redirect devices to new mailboxes. If the user’s mailbox was not found in the source forest, the Client Access server would return an error message.
In short, this is the pre-update mail synchronization flow for an EAS device after a mailbox is moved from on-premises to Office 365:
- The EAS device tries to sync using the currently configured URL and hits the on-premises Client Access server.
- The on-premises Client Access server checks if the user’s mailbox is present.
- The Client Access server gets a response that the user mailbox is not found.
- The Client Access server returns a “UserHasNoMailbox” error to the mobile device, which is displayed in the form of the following error message:
Solution
A solution has been built (and shipped in above mentioned updates) to make sure mailbox moves from on-premises to Office 365 are seamless for EAS users, as well. Once the updates are installed on your on-premises servers and a mailbox is moved to Office 365, an EAS device should be able to find the new location of the mailbox and sync without any user impact or intervention.
Let’s take a detailed look at how the solution works:
Before the move, the EAS device configuration will show it is configured to sync with on-premises URL:
The flow after the mailbox is moved to Office 365:
- The EAS device tries to sync using the currently configured URL and connects to the on-premises Client Access server.
- The Client Access server checks if the user mailbox is present.
- The Client Access server gets a response that the user mailbox is not found.
- The Client Access server triggers a query to find the “TargetOWAURL” property present on the organization relationship object for the Office 365 tenant. The “RemoteRoutingAddress” property, present on the remote mailbox, is used to find the correct organization relationship.
- The Client Access server receives the TargetOWAURL configured on the Organization Relationship.
- The Client Access server sends the URL in an HTTP 451 response to the device.
- The EAS device tries to sync with the new URL, which should be successful.
- The EAS profile on the device is updated to the Office 365 URL.
From this point forward, the device will continue to sync with Office 365.
To make this work, certain prerequisites are required:
- All on-premises Exchange 2010 Client Access servers handling EAS requests must be running at least Service Pack 3 RU9.
- Exchange 2013 Mailbox roles handling EAS requests must be running CU8.
- The EAS version on the device should be 14 or higher, and the device must be able to handle 451 redirect responses.
- The Exchange on-premises organization has successfully set up hybrid with their Office 365 tenant.
- The OrganizationRelationship object must exist in the on-premises Active Directory environment and the TargetOWAURL should be populated with the Office 365 URL.
- The username and password for the user must remain the same after the move to Office 365. The user experience will not be seamless if the username or password is changed after the mailbox is moved to Office 365.
Supported and Unsupported Scenarios
Let’s take a look at what is supported and unsupported scenarios with respect to this solution.
Supported scenarios:
- This feature covers mailbox migrations from Exchange 2010 or Exchange 2013 on-premises to Office 365 (Dedicated or Multi-Tenant).
- This feature applies to devices that are EAS-compatible and that support HTTP 451 redirection.
Note: The implementation of HTTP 451 depends on each device manufacturer. The end user experience may vary based device functionality. Contact your device manufacturer to confirm if your device supports an HTTP 451 response.
Unsupported scenarios:
- This feature does not support:
- Mailboxes moved from Exchange Server 2007 to Office 365, since Exchange Server 2007 EAS version is 12.1.
- Off-boarding a mailbox from Exchange Online to on-premises.
- Cross forest mailbox move between two Exchange Server 2013 or Exchange Server 2010 orgs.
- EAS devices or applications that do not process HTTP 451 redirects will continue to require manual intervention (the Outlook app for Android and iOS devices (previously known as Acompli) is an example of this).
For all unsupported scenarios, users will get the same experience as without the solution, as described earlier.
Organizationrelationship and TargetOwaURL
The feature depends on the presence of a “TargetOwaURL” configured on the OrganizationRelationship. The Hybrid Configuration Wizard (HCW) creates and configures the OrganizaitonRelationship object and the TargetOWAURL, as well.
Here’s an example of Organization Relationship and TargetOWAURL:
You can re-run the Hybrid Configuration Wizard (HCW), if the Organization Relationship or TargetOWAURL are missing.
Troubleshooting
The solution should work as expected. However, if you are experiencing problems, here are some troubleshooting tips:
- Confirm all the pre-requisites have been met.
- Make sure the device is actually hitting the on-premises CAS. Check the HTTP Proxy or IIS Log on the CAS to make sure the device is reaching it. You can also see the server’s response. The key is to search for the name of user that is not able to connect to the server.
Examples:
IIS Log entries
Here’s an example of an error entry from the IIS logs of an Exchange Server 2010 SP3 RU8 CAS showing the error returned to the device:
1/26/2015 23:07:39 192.168.1.53 POST /Microsoft-Server-ActiveSync/Proxy/default.eas Cmd=Sync&DeviceId=AC94832BCFD9DCD19D299AD36D2CA8C5&DeviceType=WP8&Log=PrxFrom:192.168.1.63_V141_HH:
mail.batre.msftonlinerepro.com_Cpo19000_Fet19034_ExStk:H4sIAAAAAAAEAL2RzWrDQAyE74G8wx5dCH4Hpz%2fYBLcmpeci76q22s2uo5XB7tN3Q1iSU1sf2tNIMJpvQDVp9sG%2fSX4%2f6R5ch3lB%2fDw7nbRBPoBDJ9GAg5B365VSCkTVP96%2bBOS8ciQElj4x2Romp2kAm90szPrGVl37OpTX%2f6VtRxNlh%2fOfUQp9HInxDFpMuXzhgf1hj%2f1sGARNZeJrSZbXzrV4zlLDW%2b8EJ1H6rL8IK8EZG3OSbrEj17DXGMIejyMGyUqRISX3l3mjinBigrUt6A8F19tGPbXvqEVFI8MdCMQy69Wpcwnh0ddAtvXTFzY61Nj5AgAA_S123_Error:
UserHasNoMailbox_Dc:BonDC1.contoso.com_SBkOffD:L%2f-480_TmRcv23:07:20.2281657_TmCmpl23:07:39.2625704_ActivityContextData:ActivityID%3d14988279-6caf-4565-8363-4ed43211bc35%3bI32%3aATE.C%5bBonDC1.contoso.com%5d%3d2%3bF%3aATE.AL%5bBonDC1.contoso.com%5d%3d0%3bI32%3aADS.C%5bBonDC1%5d%3d2%3bF%3aADS.AL%5bBonDC1%5d%3d1.75745_ 444 CONTOSO\Mig8 192.168.1.63 - - 200 0 0 19050
Here’s an example of an error entry from the IIS logs of an Exchange Server 2013 CU8 Mailbox server, showing a successful HTTP redirect response sent to the EAS device:
2015-01-22 13:37:53 192.168.1.61 POST /Microsoft-Server-ActiveSync/default.eas User=user12@batre.msftonlinerepro.com&DeviceId=RSUA4U03JH48LAS6T7BD2TENV0&DeviceType=iPad&Cmd=Ping&Log=
RdirTo:TryToFigureOutEasEndpoint%3bhttps%3a%2f%2foutlook.Office 365.com%2fMicrosoft-Server-ActiveSync_V141_LdapC6_LdapL31_UserInfo:MailUser_Dc:BonDC1.contoso.com_Budget:(D)Conn%3a1%2cHangingConn%3a0%2cAD%3a%24null%2f%24null%2f0%25%2cCAS%3a%24null%2f%24null%2f0%25%2cAB%3a%24null%2f%24null%2f0%25%2cRPC%3a%24null%2f%24null%2f0%25%2cFC%3a1000%2f0%2cPolicy%3aDefaultThrottlingPolicy%5Fa53e58b3-edc1-4c36-be2c-0eec854b8637%2cNorm%5bResources%3a(DC)BonDC1.contoso.com(Health%3a-1%25%2cHistLoad%3a0)%2c%5d_ 443 user12@batre.msftonlinerepro.com 192.168.1.65 Apple-iPad2C2/1202.440 451 0 0 328
3. Verify the RemoteRoutingAddress
After user’s mailbox is moved from on-premises to Office365, the on-premises user object is converted into RemoteMailbox, and “RemoteRoutingAddress” is stamped on the user.
The RemoreRoutingAddress, stored in the “TargetAddress” Attribute, is used by on-premises Client Access servers to find out the correct Organization Relationship. On-premises Client Access servers try to find the Organization Relationship where the DomainName matches the SMTP domain of RemoteRoutingAddress.
Example:
RemoteRoutingAddress of the user is @Batre.mail.Onmicrosoft.com
Which is matching the following Organization Relationship:
In this case, the on-premises Client Access server will return TargetOWAURL from this Organization Relationship.
Conclusion
The EAS on-boarding solution will make it much easier for EAS users whose mailboxes are moved from Exchange on-premises to Office 365, because it provides a mechanism for the mobile device to be redirected to the Office 365 mailbox without user intervention.