Silent OWA Redirection for Exchange 2013 / Office 365 Hybrid

If you have Exchange 2013 on-premise and configured in hybrid mode with office 365, users with office 365 mailboxes who login to the on-premise Exchange owa website receive a static link that they must click on manually.

Steve Goodman’s post goes a long way to solve this problem for Exchange 2010, but not for Exchange 2013. Here is a non Microsoft approved solution to this issue.

By default the Exchange 2013 Hybrid wizard will set the TargetOwaURL to the onmicrosoft.com portal.  This address forces end users to type in their email address in the microsoft portal before being directed back to the federated login page.  Because the user has already logged in to owa, this extra step is not needed. Run the following command to set the appropriate TargetOwaURL from the Exchange on-premise servers.

#run this command to get the correct identity of the Exchange Online relationship

Get-OrganizationRelationship

#Choose a targetowaurl simliar to: https://mail.office365.com/owa/federateddomain

Set-OrganizationRelationship -Identity "On-premises to O365 - dce3beca-eaad-43dc-939e-2f41135hj317ee" -TargetOwaURL "https://mail.office365.com/owa/federateddomain"

Now on to the good stuff. Let’s modify the errorFE.aspx file found at:Exchange 2013 install location

Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\errorFE.aspx

Make a copy of this file before modifying it.  Now enter the following:

<% if (ErrorInformation.RedirectionUrl == "https://mail.office365.com/owa/federateddomain") { Response.Redirect("https://mail.office365.com/owa/federateddomain"); }%> 

directly after this line:

<div class="errorDetails"><%RenderErrorDetails();%></div>

That is it!! The ErrorInformation.RedirectUrl variable does not get set until the RenderErrorDetails() function is called.  Hope this helps!

Advertisements

About Parker Jardine

Manager of Systems Administration in the Information Technology Higher Education space. I enjoy biking, climbing, hockey, camping, mountaineering, hunting, paragliding, and just being outdoors. You can read my Make Magazine project articles about a diy solar panel and solar systems design in volumes 12 and 14.
This entry was posted in Exchange 2013, Office 365. Bookmark the permalink.

19 Responses to Silent OWA Redirection for Exchange 2013 / Office 365 Hybrid

  1. Peter says:

    Works great, thanks!

    Like

  2. Joshua says:

    i am try to make this work currently and i am getting a 505 page cannot be displayed.

    where exactly do i put this in the file?

    Like

    • Parker Jardine says:

      Joshua,
      Simply search the file for the div class=”errorDetails” text. Then copy the redirectionurl line directly below it.

      Also make sure you replace the federateddomain with your unique federateddomain. Let me know if this helps, otherwise I can post more code, but this should do it.

      Like

  3. Frank says:

    Parker,

    I am a bit confused, am I changing the federated domain 3 times? In the set-organizationrelationship cmd as well as the 2 times in the line I am adding to the errorFE.aspx file?

    Thanks!

    Like

    • Parker Jardine says:

      Frank,
      Yes, the set-organizationrelationship command with the targetowurl is used to get the correct targetowaurl redirection to office365. By running this command, you will see that Exchange will give you the correct link that end users will have to click on. Verify that this works first before modifying the errorFE.aspx file. Once the manual redirection works, then you can proceed with the silent or auto redirection using the errorFE.aspx file. Within the errorFE.aspx file, you will enter your federated domain twice (so you are correct). The first instance ErrorInformation.RedirectionUrl matches the targetowaurl that you set in the above command. The second part of that line of code executes a silent or auto redirect to that same url, thus providing auto login to office 365. Let me know if this does not make since or if you have more questions. Thanks!

      Like

  4. Brendan says:

    I am finding that this does not work until end users clear their cache. Are you aware of any such issue or way to get around clearing cache?

    Like

    • Parker Jardine says:

      Brendan,
      I have not actually seen this be a problem for our environment. I did make these changes well in advance of our mailbox migration to office 365. I think our browsers are typically configured to delete the cache when they close, so this should prevent what you are referring to.

      Like

  5. Michael says:

    I got this to redirect, but it just redirects the user to an office 365 login page. Am I missing something?

    Like

    • Parker Jardine says:

      Michael,
      Yes, you are probably missing the following command:
      Set-OrganizationRelationship -Identity “On-premises to O365 – dce3beca-eaad-43dc-939e-2f41135hj317ee” -TargetOwaURL “https://mail.office365.com/owa/federateddomain”

      Remember to replace your Identity and TargetOwaURL with appropriate values. I usually run a get-organizationrelationship command to acquire the existing Identity value. Your federateddomain would be the domain that you have setup with Office 365. Let me know if this helps.

      Like

  6. Eliezer says:

    hello. I used this help, it worked fine with chrome and firefox, but not on internet explorer/microsoft edge. Do you have any solution for internet explorer/microsoft edge

    Like

    • Parker Jardine says:

      Eliezer,
      This solution works for edge and IE on our computers (several thousand computers), so something else must be going on. What error are you receiving?

      Like

  7. Cory Berends says:

    I am having the same issue Chrome and Firefox work, but IE doesn’t. I get a “This page can’t be displayed” error and the address line of IE has https://mail.mydomain.com/owa/auth.owa

    Like

    • Parker Jardine says:

      Cory, what version of IE are you having issues with? I have verified that version 11 works on my end. Also, does it look like it tries to redirect, but then gives you the error, or no redirection at all?

      Like

  8. Simon says:

    Worked a treat, thanks!

    Like

  9. Martin says:

    works perfectly but only in Chrome – for some reason IE is just giving me an error saying Something Went Wrong. It doesn’t give the URL that it should be re-directing to?

    Like

  10. Joshua says:

    Have you tested this with Exchange 2016? i am currently performing an upgrade and the new redirection URL is different. It now has a username in it. Is there a variable that we can use?

    Like

    • Joshua says:

      After playing with it this the 2016 version since it puts your username in it.

      Like

    • Parker Jardine says:

      I have not tested this with Exchange 2016. Most of my users have already been migrated to Office 365. We currently have Exchange configured to authenticate ADFS. The authentication response from ADFS for Exchange contains a set of claims within the auth token. So once the auth token gets back to exchange, there is no need for exchange to send the username in the redirection to Office 365. We also authenticate Office 365 with ADFS, so the auth token granted from on-prem owa is accepted and additional claims are sent to Office 365. In my environment, I would suspect that I could safely ignore the additional username that is being sent. However, I have not tried this.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s