Back in March of 2016, Microsoft released Cumulative Update 8 (CU8) for Exchange Server 2013. By now, we’re all used to the idea that cumulative updates (and not just service packs) have become a vehicle to introduce new features into Exchange. Hence, it is no surprise that CU8 comes with a bunch of new features and improvements alongside a boatload of bug fixes.
Microsoft introduced new “hybrid” features way back in Cumulative Update 5. So you can imagine how gratifying it was to learn that CU8 contained an important improvement in hybrid deployments with Office 365.
Before we dive into the feature itself, I’d like to give some background information on the problem the feature will help solve. A hybrid deployment is often deployed to allow the so-called “hybrid mailbox moves” (sometimes you’ll also see them referenced as “MRS mailbox moves” or “remote mailbox moves”). Regardless of what name you use, my opinion is that these mailbox moves offer significant value over other migration methods. The simple reason is 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 may think this is not really a problem, try to imagine how that would feel for an organization that has limited bandwidth but has several hundred gigabytes or maybe even terabytes worth of mailbox data as a whole. In such scenario, if you can avoid having to download the data which was just “uploaded” to Office 365, then that is something you might want to look into.
Anyway, 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. Oops—that wasn’t what you’ve expected, huh? And you’re right. Because this means 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 their mailbox, this approach is not really flexible and can drain IT resources and your helpdesk. Not to mention that it is extremely time-consuming. Luckily some third-party mobile device management solutions allow you to centrally manage 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 do. 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? Well, 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 cover, 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:
The EAS clients connects to the on-premises Exchange server(s). This is because the profile of the EAS client still points to the on-premises environment:
Exchange will now look for the mailbox.
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.
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.
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/tenant.mail.onmicrosoft.com
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-07-21 07:20:50 192.168.1.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.myserver.net_……. AL%5bDC01%5d%3d10.4515_ 444 EXCHANGELAB\dlewis 192.168.1.101 – – 451 0 0 20103
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 seems 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 should 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 Organization 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 and password must not change when the mailbox is moved to Office 365. Although this is rather important, most hybrid deployments that I have worked with have implemented SSO anyway. Whether you use ADFS, IDP, or DirSync with Password Sync should not matter. So if you set up EAS profiles with an on-premise 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; I would look for this to change with Exchange Server 2016.