Enabling Silent OWA Redirection for Office 365 Hybrid

As part of a Hybrid deployment of Exchange Server 2010 and Office 365, you’ll be faced with a few challenges if you want to keep a single Outlook Web App URL for your end users.

If you’re using Windows Authenticated Login against Exchange and AD FS then you’ll already have avoided multiple login prompts; and if you’re using Forms Based Authentication for both I’ll be covering the TMG setup necessary to configure the same single sign on you’ll see in the videos here in a future article. (based in part by a post Michel De Rooij pointed me to here).

The other challenge that I really wanted to get a solution for, and get feedback from others on, is the landing page shown above where the end user needs to click-through the “Use the following link to open this mailbox with the best performance” page. What I wanted was a solution that avoided that step entirely.

Now, it’s not necessary to do this if you are happy for users to update their own bookmarks, and concerns about users seeing a non-company domain can be avoided by following the steps in this article by Timothy Heeney which shows you how to setup a separate vanity Office 365 URL like “http://cloud.company.com/owa” by using CNAME records.

However if you have a large user base that will be mixed between on-premise and Office 365, then keeping a single OWA URL will be very desirable. For example, a large University may have user documentation with the URL specified, lab computers with standard bookmarks, and the possibility that users may move between on-premises and Office 365 as they move between different courses or roles. It might only be an extra click, but if you add up that extra 5 seconds across tens of thousands of users logging into OWA per day and it starts to add up..

If you’re not familiar with the process, here’s a quick demo of the current “out of the box” experience, optimised using TMG for forms-based single sign-on:

As you can see it’s good – but it’s not great. It’s not got the “wow” factor that makes a hybrid deployment feel like a single organization.

The redirect page itself does serve other purposes, so it’s not like we can just get rid of it. It’s used by Exchange itself if you have an environment with multiple internet facing sites, unless you use the SP2 feature for silent redirection between sites. So we can’t just do away with the redirection page altogether – we need to take into account where it might be used elsewhere.

Another issue that’s been highlighted to me (thanks BR!) is that the default non-SSL link generated through the Hybrid Wizard is in the form http://outlook.com/owa/federateddomain rather than it’s SSL equivalent – so using this (or the vanity URL mentioned above) could generate browser warnings regarding redirection to a insecure link. Therefore the link we redirect to must be in the form https://outlook.com/owa/federatedomain. This can be changed easily though, by editing the Organization Relationship like so:

Set-OrganizationRelationship "On Premises to Exchange Online Organization Relationship" -TargetOwaURL:https://outlook.com/owa/federateddomain

Once this is changed, we should be ready to enable the silent OWA redirection in Exchange itself, by editing the casredirect.aspx file within OWA.

Before we begin – it’s important to understand that this is unsupported by Microsoft, and it probably never will be. Therefore, you’ll need to test this in your own environment, and be prepared to replace the original casredirect.aspx file in the event of any issues; you’ll also need to check and if needed, re-implement this after application of update rollups or service packs. That said, so far I can’t see a reason why this would cause any issues and part of the point of this post is to gain some feedback from the community as to any other downsides.

So now you know why you shouldn’t do this – let’s look at how to do it..! You’ll find the casredirect.aspx file within the OWA directory, typically in the following path within the Exchange install directory:

C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\owa\

Edit the casredirect.aspx file directly above the <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> tag and add the following lines:

<%
if (RedirectionUrl.Contains("https://outlook.com/owa")) {
    Response.Redirect(RedirectionUrl);
    Response.End();
}
%>

This should look like this in the actual file itself:

What does this do? Well, it’s pretty straightforward – before any content is rendered, the Redirection URL is checked to ascertain if it contains the https://outlook.com/owa URL (note the HTTPS!), and if so, issue a redirect to Office 365. For any other Redirection URLs, the page will render normally.

Let’s take a look at how it works in practice:

As you can see it’s fairly simple to implement, and provides a clean login consistent with on-premises Outlook Web App when combined with other SSO methods. Let me know what you think in the comments…

Steve