none
Redirect UAG URL to OWA RRS feed

  • Question

  • We have our exchange 2010 OWA published through UAG with an external address of webmail.company.com.  If a user goes to https://webmail.company.com/owa they get redirected directly to OWA after signing in, but if they just go to https://webmail.company.com they go to the portal after signing in.  I can't change the default application on the trunk because we also have Sharepoint published in the trunk which is working exactly as I want webmail to work.  When a user goes to http://sharepoint.company.com they go directly to sharepoint.  How can I get the same behavior with OWA?

    Friday, August 5, 2011 2:47 PM

Answers

  • Hi Clint,

    i'm not aware of a "simple" workaround in this specific case. But i have two ideas which i want to share with you.

    1. You could configure a second trunk for the exchange application(s) and enable Cross-Trunk SSO betwenn the trunks. On this way you could set two different default applications.

    2. You could trigger the redirect on your OWA site (IIS). To do that, you have to reconfigre the path and URL filtering settings of the OWA releated UAG publishing rule to include the "/"(root). Once done, you have to configure the 302 HTTP redirect on the default dokument of your OWA root folder. 

    -Kai

     


    • Marked as answer by Clint A Monday, August 8, 2011 4:10 PM
    Friday, August 5, 2011 7:21 PM

All replies

  • Hi Amig@. You can publish OWA with an specific hostname instead of using the portal name (owa.company.com). Just the same you do with SharePoint.

    Regards


    // Raúl - I love this game
    Friday, August 5, 2011 6:05 PM
  • Can you explain?  I published Exchange 2010 which includes owa, and under the "Web Servers" tab in the Exchange Server 2010 Application properties I have webmail as the public hostname.  What more needs to be done to make this work?
    Friday, August 5, 2011 6:12 PM
  • Hi Clint,

    i'm not aware of a "simple" workaround in this specific case. But i have two ideas which i want to share with you.

    1. You could configure a second trunk for the exchange application(s) and enable Cross-Trunk SSO betwenn the trunks. On this way you could set two different default applications.

    2. You could trigger the redirect on your OWA site (IIS). To do that, you have to reconfigre the path and URL filtering settings of the OWA releated UAG publishing rule to include the "/"(root). Once done, you have to configure the 302 HTTP redirect on the default dokument of your OWA root folder. 

    -Kai

     


    • Marked as answer by Clint A Monday, August 8, 2011 4:10 PM
    Friday, August 5, 2011 7:21 PM
  • If I try to add "/" to the Paths in the "Web Servers" tab of the Exchange application properties I get the following error:

    The application you're trying to configure is conflicting with an existing application "Exchange - EWS". To continue, please disable the conflicting application, or give one of the applications a different host name.

    Is this not possible if also publishing Exchange EWS?

    Friday, August 5, 2011 8:06 PM
  • You have to use a dedicated URL for OWA, since UAG don't allow overlapping rules.

    -Kai

    Friday, August 5, 2011 8:20 PM
  • Hi all. My workaround is more simple than that. Edit the properties of your OWA publication. In the "web servers" tab there is a box that says "public host name". By default this field is completed with the public name of the portal but you can write a different one (that will be an application specific hostname, just like SharePoint). Register that name in DNS to the same IP of the portal and include a SAN in the portal certificate including that name.

    Regards


    // Raúl - I love this game
    Monday, August 8, 2011 6:16 AM
  • Hi Raul,

    i think you've misunderstood his question a little bit. He did already assigned a dedicated "Public Host Name" for the OWA access and this is working "as intended".

    But he has still problems with the "intended behavior" when some "lazy" users are entering the wrong base URL ( e.g. https://webmail.domain.tld/ instead of https://webmail.domain.tld/owa/ ). In this case the users won't be redirected to OWA, but instead they will be redirected to the Portal Page (located on the default AAM).

    Since UAG doesn't have a build in mechanism to redirect those request transparently, i've posted the two more or less complicated workarounds to get it up and running. If you know a third workaround to have those request become redirected then let us know...

    -Kai

     


    Monday, August 8, 2011 8:25 AM
  • Well, for me the trick is to configure UAG to accept the initial "/" and then let Exchange to do the redirection (it should be already done for internal users). The public name of Exchange and the Portal are different so there is no overlapping (just the same than in SharePoint). Makes it sense?  


    // Raúl - I love this game
    Monday, August 8, 2011 8:47 AM
  • Hi Raul,

    this is exactly the way i've described in my second workaround.

    -Kai

    Monday, August 8, 2011 9:01 AM
  • Summer holidays...
    // Raúl - I love this game
    Monday, August 8, 2011 12:15 PM
  • Could I remove the Exchange - EWS application and just add /OAB/, /Ews/ and /UnifiedMessaging/ to the Paths in the Exchange application?  This would allow me to use the / path in the Exchange application because it would remove overlapping rules, but I'm hesitant to do this because I presume the UAG wizard had some reason why it created them as seperate applications in the first place.
    Monday, August 8, 2011 2:10 PM
  • Hi Clint,

    this is exactly why i considered this workaround as a "not simple" one.

    The UAG wizards are very integrated and will create a very optimized configuration for each of the different Exchange applications. If you include the EWS paths to your OWA application they will both share the underlying configuration (AppWrap, Parsing exemptions, URL rules, auth settings, etc.). So doing this would most likely just break EWS, since it requires a lot of additianal, manual and also complex configuration to make it right...

    Well, using OWA on a seperate URL is the only way to get an "almost" supported configuration in this case, since you will only add the 302 redirect to the OWA application without hacking the rules that much.

    -Kai

     


    Monday, August 8, 2011 3:04 PM
  • Hi Clint,

    i've just found a programatic way to redirect the OWA request by using a very simple postpostvalidate.inc code snipped.

    <%
    
    If Instr(GetSessionParam(g_cookie, "Hybrid_WhlStatusFlagP"), "mail.contoso.de") <> 0 then
    	g_orig_url = "https://mail.contoso.de/owa/"
    End if
    
    %>
    

    -Kai

     

    • Proposed as answer by Kai Wilke Thursday, September 8, 2011 10:23 PM
    Thursday, September 8, 2011 9:55 PM