If you would like to read the prevoius part in this article series please go to:
If you would like to read the next part in this article series please go to Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 33).
Introduction
In part 31 of this article series revolving around what the Windows Azure service is all about as well as how you deploy an Exchange hybrid deployment in Windows Azure, we took a look behind the scene at what happens with a mailbox user, when his mailbox is moved to Exchange Online. Furthermore, we looked at how you can bulk assign licenses to the users.
In this part 32, we will continue where we left off in part 31. That is, we will take a look at the client experience, when a mailbox has been moved from an on-premises Exchange environment to Exchange Online.
Let’s get going…
Client Experience
So when an on-premises mailbox move request has completed, the source Active Directory object will be converted to a mail-enabled user (MEU) object which will have a target address (forwarding address) in the form of “alias@tenant_name.mail.onmicrosoft.com”, so that any mail or autodiscover request, that hits the MEU object on-premises will be routed/redirected to Exchange Online Protection/Exchange Online and from here go to the respective mailbox in Exchange Online.
In the following steps, I’ll explain how a mailbox move to Exchange Online will affect the Outlook desktop client, Outlook Web App (OWA) and ActiveSync based devices.
Outlook Desktop Client
When the mailbox has been migrated to Exchange Online, while the Outlook desktop client is running, the user will receive the following dialog box informing him that the Exchange administrator has made changes and the Outlook desktop client need to be restarted for the changes to take effect at the client layer.
Note
Often the end user will receive this dialog box twice.
Figure 1: The Exchange Administrator has made changes that require Outlook to be restarted
When the Outlook desktop client has been restarted, it will initiate a new autodiscover request against the on-premises Exchange environment and then detect that the mailbox has been converted to a MEU object that points to the mailbox in Exchange online using the “alias@tenant_name.mail.onmicrosoft.com” routing address. The Outlook desktop client is then redirected to the autodiscover service in Exchange Online (autodiscover.outlook.com which then based on region location of the client will redirect to the proper region specific autodiscover endpoint, which in my case is: autodiscover-emeacenter.outlook.com). Since Outlook clients authenticate to Exchange Online using basic authentication, the user will be told to enter his credentials in order to connect to his mailbox in Exchange Online. The user will enter his UPN and password and at the same time, it’s recommended to tick the “Remember my password” box, so that Outlook won’t prompt for credentials next time it’s started.
Figure 2: Outlook prompts for credentials when connecting to the mailbox in Exchange Online
As mentioned Exchange Online currently use basic authentication to authenticate Outlook desktop clients. However, a new Active Directory Authentication Library or in short ADAL based authentication model known as modern authentication in Office 365 terminology is currently being enabled on Office 365 tenants in all regions.
Modern authentication will provide us with a much better authentication story for the Outlook desktop client. In that this client will be able to authenticate in the same ways as passive clients (i.e. browser based clients). This means that the Office 365 credentials no longer need to be stored in the credential manager on the local client in order to get SSO. It’s important to note though that modern authentication only will work with Outlook 2013 and later versions and must be enabled on the client using a registry key.
Outlook Web App (OWA)
Before we look at how a mailbox move affects the OWA client, let’s talk about some logic that this client utilizes. So Back when we configured Exchange hybrid using the HCW, the wizard (among other things) populates the target OWA URL, which is a property on the organization relationship that gets created, when we run the HCW. In Figure 3, we can see my specific target OWA URL is set to “http://outlook.com/owa/azurelab.dk”.
Figure 3: Target OWA URL on the Organization Relationship object
When a user accesses the OWA endpoint in the on-premises (in my case: “https://mail.azurelab.dk/owa“), the Exchange user will be presented with the Exchange 2013 on-premises login page and after successful authentication get access to his on-premises mailbox. Nothing new here. Standard stuff right.
Figure 4: OWA 2013 Login Page
When a user that had his mailbox moved to Exchange Online tries to access his mailbox using the same on-premises OWA URL (https://owa.office365lab.dk/owa), Exchange 2013 on-premises will detect that the users mailbox does not exist locally and based on the routing address (“alias@tenant_name.mail.onmicrosoft.com” or in my case“[email protected]) set on the MEU object for the user, try to find an organization relationship with this domain name (azurelab.mail.onmicrosoft.com) and if it finds it, lookup the target OWA URL and based on the value of it provide the information to the user after he authenticated successfully on the Exchange 2013 on-premises login page shown in Figure 4.
Figure 5 shows the page with the link that can be used to access the mailbox in Exchange Online.
Figure 5: Non-transparent OWA redirect URL
When clicking the link depending on whether the user is logged on to a domain-joined machine or not, he will be either authenticated transparently or will be redirected to the AD FS login page and once again provide his credentials.
Figure 6: Redirected to AD FS login page for authentication
Since the OWA redirection uses what we refer to as an non-transparent redirection experience, the end user may want to save the link provided in his favorites. Alternatively, you could create a new CNAME record such as “cloudmail.contoso.com” that points to “outlook.office365.com” for users that had their mailbox migrated to Exchange Online or simply point the existing (mail.contoso.com) record to point to Exchange Online once all user mailboxes has been moved.
ActiveSync Devices
When it comes to devices that synchronizes with an Exchange on-premises mailbox, when you moved a mailbox from an on-premises Exchange environment to Exchange Online using the remote move request feature, the Outlook client will be re-configured automatically (using autodiscover) and Outlook Web App (OWA) will be re-directed to the correct Exchange Online URL based on the target OWA URL.
Good and transparent experience for the end users as would be expected when using the Exchange hybrid deployment approach right? Your conversation with the customer (that is eager to move to Office 365) is all good and then the talk turns to mobile devices and tablets. What? You tell me that my user’s need to re-configure their mobile devices and tablets manually after their mailbox has been moved to Exchange Online?!?! You’re kidding right? No unfortunately not. When the mailbox is moved to Exchange Online there’s no logic in the Exchange code, that can make the required re-direction.
I bet many of you have been in this situation right? So with the release of Exchange 2013 CU8 and Exchange 2010 SP3 UR9, we finally have a good story for mobile devices and tables utilizing the Exchange ActiveSync protocol. More specifically, all Exchange ActiveSync devices that can handle the HTTP 451 redirection error code will be re-configured automatically as long as you have deployed an Exchange hybrid configuration and that the target OWA URL exist in the organization relationship. In addition, the sourced mailbox must be stored on either Exchange 2010 or 2013. Exchange 2007 or earlier is not supported. It’s also worth noting this feature doesn’t support off boarding mailboxes from Exchange Online to an on-premises Exchange environment.
The is a small new feature or should we call it an improvement, but definitely an important one of its kind.
This concludes part 32 of this multi-part article in which I provide you with an explanation of what Windows Azure is and how you configure an Exchange 2013 hybrid lab environment in Windows Azure.
If you would like to read the prevoius part in this article series please go to:
If you would like to read the next part in this article series please go to Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 33).
