Baran711
asked on
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.
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.
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?
ASKER
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>
<rule name="Redirect to https">
<match url="(.*)"/>
<conditions>
<add input="{HTTPS}" pattern="Off"/>
</conditions>
<action type="Redirect" url="https://www.blah.com/owa"/>
</rule>
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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_U RI}" appendQueryString="true" redirectType="Permanent" />
</rule>
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_U
</rule>
ASKER
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_U RI}" appendQueryString="true" redirectType="Permanent" />
</rule>
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_U
</rule>
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"
You may need to use "off", instead of "Off"
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.
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.
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.
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.
ASKER
Thanks, at this point i am going to close the issue and consider it resolved. The need for http://servername is not significant.