Exchange ActiveSync on-boarding to Office 365

[The_Exchange_Team]

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:

1. The EAS device tries to sync using the currently configured URL and hits the on-premises Client Access server.
2. The on-premises Client Access server checks if the user’s mailbox is present.
3. The Client Access server gets a response that the user mailbox is not found.
4. 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:

1. The EAS device tries to sync using the currently configured URL and connects to the on-premises Client Access server.
2. The Client Access server checks if the user mailbox is present.
3. The Client Access server gets a response that the user mailbox is not found.
4. 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.
5. The Client Access server receives the TargetOWAURL configured on the Organization Relationship.
6. The Client Access server sends the URL in an HTTP 451 response to the device.
7. The EAS device tries to sync with the new URL, which should be successful.
8. 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:

1. Confirm all the pre-requisites have been met.
2. 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.

Bhalchandra Atre

[#2]

@Team

Why this doesn't affect E2007 also as E2007 MBX in hybrid environment is not in connection flow. SPOC is CAS Hybrid which is E2010...

[#3]

@DavidR1: Sorry about that; it seems like we have a platform issue of some sort where the blog does not serve graphics properly at all times for all users. I had an issue like this too for a day there but now it seems fine... it is being looked into and

I believe it is wider than our blog alone.

[#4]

For some reason, all of the graphic links on this particular article seem to be invalid (404-file not found).

[#5]

Yawn....

This feature does not support:

-Cross forest mailbox move between two Exchange Server 2013 or Exchange Server 2010 orgs.

Absolutely unacceptable. What justification have you got for not bringing this to cross forest mailbox moves? We do 20+cross forest migrations per year as part of acquiring other businesses and this is a MUCH needed feature and not having it really let's the

slick mailbox move process down in my opinion.

You're not going to force us to migrate to the cloud just because you continue to release features in Office 365 that you won't release on-prem. You'll just push us anyway eventually to the point where we will migrate our email platform to another product.

[#6]

Well written & Thanks for the update....

Valid point / feedback to be considered from Ash & looking forward to hear from Exchange team !!

[#7]

Will this feature allow Intune to provide seamless MDM device migrations or does this only work for direct EAS management?

[#8]

Great news, but somewhat limited if you are using an enterprise mobile device admin like we are. Also, since Office 365 only supported NTLM authentication for ActiveSync, if you are using Kerberos Constrained Delegation for authentication with your MDM

(like we are) you are still forced to reconfigure the device once you migration the mailbox. But I can see this change as an important one for other businesses not using KCD authentication with an MDM solution.

[#9]

Is there still are reliance on primary SMTP address matching User Principal Name. This has forever been a thorn in our side with autodiscover.

[#10]

Cool, this is a step in the right direction. However.. O365 requires a UPN to log in to Activesync. And I doubt many users type in their full UPN to sync their on-premise Exchange email, I might be mistaken but the majority of users will have entered a

"domainuser" username format.

But I guess we can tell users to use the UPN format in preparation for a more seamless migration.

[#11]

Has anybody compiled a list of common mobile devices which support the HTTP 451 redirect. I heard it was only Windows Phone.

[#12]

With regards to devices and app that does not support HTTP 451 response, is there a list we could check this?

Is it device or app specific? or both?

[#13]

Can you explain more in detail this one:

Mailboxes moved from Exchange Server 2007 to Office 365, since Exchange Server 2007 EAS version is 12.1.

because, all handling is done on CAS which in hybrid configuration is 2010...

and on connection flow diagram, there is only CAS involved...

[#14]

Images are not showing for me, can anyone else see these?

[#15]

I have a couple questions: The obvious one - will ios devices support this? and will this work if our users are connecting to the on-premise environment with sAMAccountName but we are using UPN to connect to Office 365?

[#16]

great article but not all images are loading for me?

[#17]

Excellent article. But the images does not load?

[#18]

Is there a necessity for primary SMTP address to match User Principal Name. This is always a problem for us, that so much of Autodiscover and ActiveSync relies on these two things being the same.

[#19]

Hello. With regards to the supports for HTTP 451 response, is that device or application specific?

Tried asking Apple but they do not know.

[#20]

When you mention the pre-requisite that 'The username and password for the user must remain the same after the move to Office 365.', what does this really mean? We are migrating users to 365 and changing their UPN to match the primary SMTP address. Is

this a username change or not, in the context of this solution? Thanks

[#21]

What if you are using activesync allowed devices? Currently the msexchmobilealloweddeviceid attribute does not get copied to Exchange Online when you move the mailbox, it has to be copied manually or with a script.

Without copying the attribute this feature is fairly useless because the device will get blocked or quarantined as soon as the mailbox moves, therefore the administrator will still need to punch in the device list. Not very seemless.

[#22]

Thanks for this Update, but 100% Agree with Ash12345678: A seamless migration for Cross forest mailbox moves would be highly needed! (much more than for O365)

[#23]

The images are still broken, just so you know.

[#24]

I would assume this wouldn't work if

1. The environment uses ADFS

2. The user isn't using Outlook App

Is that correct?