[Webinar] Streamline your web hosting managementRegister Today

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 641
  • Last Modified:

OWA url re-write in IIS

I have a 2012 server running exchange 2013 (not yet in production). I am trying to use URL Rewriter to redirect http requests to https requests for owa. We have content under the default website so I cannot simply redirect requests to the default website to /owa with ssl.

I thought it was possible with URL rewriter to change a request for http://www.webhost.com/owa to https://www.webhost.com/owa 

does anyone have any first hand experience doing this, I have found a few examples and they do not seem to work. I can verify my patern matches but I believe I am not getting a match when I try {HTTPS}=off or {HTTPS}=^OFF$ if anyone can give me a complete urlrewriter rule that would be great.

for the time being I created mail.webhost.com as a secondary site and have that as a perm redirect to https://www.webhost.com/owa this works but it is less then ideal and would like to use url rewriter if possible.
0
Baran711
Asked:
Baran711
  • 5
  • 4
1 Solution
 
LeeDerbyshireCommented:
It's a while since I played with this, and I'm not really able to do much testing of this sort of thing any more, but can you paste for us how the relevant <rewrite/> section looks in the web.config file?
0
 
Baran711Author Commented:
I have made some progress but would still like to refine it if possible. In the owa virtual directory config I have placed the following. It works for 2 reasons 1, its in the owa virtual directory so it only fires at the appropriate time, and 2 I can live with it redirecting to the root fqdn for now since once it does that the user is using ssl and should be ok. I would prefer it to verify that they are at the owa page in the match url, and I would rather rewrite the original url and just switch it to https as apposed to just blanketing it with the predefined fqdn/owa. I tried putting "owa" in the match url as well as "/owa" but neither seemed to fire.



        <rule name="Redirect to https">

          <match url="(.*)"/>

          <conditions>

            <add input="{HTTPS}" pattern="Off"/>

       

          </conditions>
        <action type="Redirect" url="https://www.blah.com/owa"/>

        </rule>
0
 
LeeDerbyshireCommented:
I'd try

<match url="(^owa/.*)" ignoreCase="true" />

although you won't need that if you're putting it in the owa web.config.  And maybe

<action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" appendQueryString="true" redirectType="Permanent" />
0
Easily manage email signatures in Office 365

Managing email signatures in Office 365 can be a challenging task if you don't have the right tool. CodeTwo Email Signatures for Office 365 will help you implement a unified email signature look, no matter what email client is used by users. Test it for free!

 
Baran711Author Commented:
that didn't quite work but it may not be your fault, I do not understand asp enough to know if this could be related to the way Microsoft coded owa. the behavior is weird. with your rule I get the following results:

if I goto http://servername/owa the rule fires correctly and everything worked as expected.

if I goto http://fqdn of server/owa it does not redirect
if I goto http://publicfqdn/owa it does not redirect



interestingly enough, with my solution using the match patern of * and a full fqdn redirect it worked for the server fqdn/owa and the public fqdn/owa but not the NetBIOS name. so essentially I get the complete opposite results with your rule then I did with mine. the reality is having the public fqdn redirect and the server fqdn redirect is more relevant then just the server NetBIOS name. I am not sure why the distinction is occurring though. I just wonder if owa is doing something a the time of access that somehow invalidates something.  

It is odd because the match statement is focusing on owa and not the fqdn....

here is how I implemented your rule:

      <rule name="Redirect to https">

         <match url="(^owa/.*)" ignoreCase="true" />

          <conditions>

            <add input="{HTTPS}" pattern="Off"/>

       

          </conditions>
       <action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" appendQueryString="true" redirectType="Permanent" />

        </rule>
0
 
Baran711Author Commented:
just an update if I use the following it works for server fqdn/owa and public fqdn/owa

it does not work for http://server/owa but I think I can live with that For my own sanity if anyone knows why I would appreciate any explanation you can offer

The initial issue with yours must have been in the match statement. As I mentioned this is running in the owa virtual directory only so the match statement is not overly critical.



        <rule name="Redirect to https">

         <match url="(.*)" ignoreCase="true" />

          <conditions>

            <add input="{HTTPS}" pattern="Off"/>

       

          </conditions>
       <action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" appendQueryString="true" redirectType="Permanent" />

        </rule>
0
 
LeeDerbyshireCommented:
Is there a chance that some of your tested urls are being picked up by the other site you created? Did you give it a host header name?

You may need to use "off", instead of "Off"
0
 
LeeDerbyshireCommented:
Also, have a look at this
http://www.iis.net/learn/extensions/url-rewrite-module/using-failed-request-tracing-to-trace-rewrite-rules
Note that you will specifically have to tell it to trace successful requests, too.
0
 
LeeDerbyshireCommented:
It's possible that if you have a match url starting with ^owa in owa's own web.config file, then it will actually be looking for this

http://servername/owa/owa

IOW, use ^owa/.* if you put it in the root web.config, use .* if you put it in owa's own web.config.

Or something. Rewriting for a single subdirectory doesn't seem to be well documented.
0
 
Baran711Author Commented:
Thanks, at this point i am going to close the issue and consider it resolved. The need for http://servername is not significant.
0

Featured Post

The 14th Annual Expert Award Winners

The results are in! Meet the top members of our 2017 Expert Awards. Congratulations to all who qualified!

  • 5
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now