A Closer Look at the New ActiveSync Redirection Feature in Exchange 2013 CU8

It has been since Cumulative Update 5 that Microsoft introduced new "hybrid" features. So you can imagine how pleased I was to learn that CU8 contained a rather important improvement with regards to hybrid deployments.

Before we dive into the feature itself, let me give some background information on the problem the feature will help to solve. A hybrid deployment is often deployed to allow the so-called "hybrid mailbox moves", sometimes you'll also see them referenced as "MRS moves" or "remote mailbox moves". Regardless of what name you use, in my opinion these mailbox moves offer significant value over other migration methods. The simple reason being that hybrid mailbox moves are more resilient, more flexible and almost transparent to the end user. In a staged- or cutover migration, once a mailbox is moved, Outlook's offline cache (.OST file) has to be recreated. While you might think this is not really a problem, try and imagine how that would feel like for an organization that has limited bandwidth but has several hundred gigabyte worth of mailbox data. In such scenario, if you can avoid having to download the data which you just have 'uploaded' to Office 365, then that is something you would want to look into.

Anyway, I'm digressing, let's fast-forward to right after the mailbox move to Office 365. At this point, the Outlook client will automatically reconnect to the mailbox in Office 365 thanks to some internal magic with Autodiscover (clients are automatically redirected to Office 365 after the move). Chances are that the user whose mailbox was just moved to Exchange Online also uses one, or more, mobile devices that connect to the mailbox using Exchange Active Sync (EAS). Unfortunately, prior to CU8, those devices would connect to the on-premises Exchange servers (just like before the move) only to find out that they are not redirected. Instead, the on-premises Exchange servers would return an error "UserHasNoMailbox" to the EAS client…. Darn! That wasn't what you've expected, huh? And you are right. Because this meant that after each mailbox move, the user's EAS devices had to be reconfigured to now point to Office 365. Often, this means recreating the EAS profile on the device. If you're lucky, you might be able to just update the hostname of the server and manually point it to outlook.office365.com. In a world where almost everyone has one or more devices connected to his mailbox, this approach is not really flexible. Not to mention that it is extremely time-consuming. Luckily some 3^rd party Mobile Device Management solutions allow you to centrally manage e.g. the EAS profiles on a device, but it does require you to have purchased and deployed such a solution. Again, not something that every organization has, or is willing to… As a result of all this, in many onboarding projects, the lack of something better than the manual approach is flagged as a constraint. Life would be so much better if there would just be some kind of logic that took care of this for you, wouldn't it? Hello CU8!

CU8 now contains the logic that you've been waiting for. So, let's take a look at how it works under the sheets, shall we?

The following image depicts the various interactions between an EAS client and an on-premises Exchange server, right after the mailbox has been moved to Office 365:

1. The EAS clients connects to the on-premises Exchange server(s). This because the profile of the EAS client still points to the on-premises environment:
   
   
   
   
2. Exchange will now look for the mailbox.
    
3. The mailbox does not exist as it has been moved to Office 365. Normally, a "UserHasNoMailbox" error would be returned. However, now it isn't.
    
4. a) Exchange takes a look at the targetAddress attribute of the Mail-Enabled User. This attribute is populated after the mailbox is moved to Office 365 and converted into a mail-enabled user.
   b) The domain portion of the targetAddress attribute is what will be used to look for a matching Organization Relationship.
    
5. The domain name from the TargetOWAUrl property is retrieved and returned to Exchange. You can view the value yourself by using the Get-OrganizationRelationship cmdlet:
   
   [PS] C:\>Get-OrganizationRelationship "On-pre*" | fl *url TargetOwaURL : http://outlook.com/owa/exchangelabonline.mail.onmicrosoft.com
    
6. Exchange now responds back to the EAS client with a 451 redirect. The URL that the client is redirected to is based on the TargetOWAUrl fetched in step 5. In the IIS logs (on the Mailbox Server), you will see an entry similar to the following:
   
   2015-03-26 07:20:50 192.168.30.104 POST /Microsoft-Server-ActiveSync/Proxy/default.eas Cmd=FolderSync&DeviceId=0355B4CEFD7E0CA163FDFE21F782693C&DeviceType=WP8&Log=PrxFrom:192.168.30.101_RdirTo:TryToFigureOutEasEndpoint%3bhttps%3a%2f%2foutlook.office365.com%2fMicrosoft-Server-ActiveSync_V141_HH:outlook.exchangelab.be_....... AL%5bDC01%5d%3d10.4515_ 444 EXCHANGELAB\dlewis 192.168.30.101 - - 451 0 0 20103
    
7. The EAS client will now try and connect to outlook.office365.com. Once the connection is successful, the EAS profile on the client will automatically be updated:

From testing this feature, I found that it seem to work really well. A few seconds after moving the mailbox and the EAS client was already successfully redirected to and syncing with Office 365. However, there are some caveats associated with this feature:

• The EAS client you are using must be able to handle the 451 redirect. I tested with my Windows Phone and an iPad and both worked rather well. However, not every device/client might be able to process the 451 redirect. So you better check with the manufacturer (and test!) before relying on this feature.
• The Hybrid Configuration Wizard automatically takes care of creating the Organization Relationship and populating the correct values. If, for some reason, the TargetOWAUrl for the O365 Organization Relationship is missing, this feature will not work correctly. In such case, re-run the HCW or make sure the Org. Relationship contains the necessary values.

According to the information from  this article, there are some other prerequisites and limitations too!

• To ensure the "full fidelity" experience for the end user (seamless), the username & password must not change when the mailbox is moved to Office 365. Although this is rather important, experience learns that most hybrid deployments that I have worked with have implemented SSO anyway. Whether you use AD FS or Password Hash Sync should not matter. So, if you setup EAS profiles with an on-prem Exchange server, it's best to use the UPN already.
• The EAS version on the device must be version 14 or higher. This would be the case for most modern devices anyway.
• If you have legacy Exchange server versions in the environment, please ensure that Exchange 2010 is running at least Service Pack 3 RU9. Mailboxes moved from Exchange 2007 will not be redirected.

Last but not least, if you are hoping that this feature might work between two on-premises organizations, you'll be disappointed: it doesn't. The redirect also only works when onboarding mailboxes to Office 365. If you are moving mailboxes back on-premises, you'll still have to reconfigure the EAS profile.