The Redirect Catch



Recently working a case where customer was trying to implement the approach explained by my friend Tom Shinder on his post “Clever Way to Redirect OWA Users Who Can’t Remember to Include /Exchange in the Path” and it was not working. The approach explained by Tom is valid and works, but there is a catch and this is what I will explain in this post.




For this particular case the Exchange OWA publishing rule was working, but only when we typed the full path, in this case , however the goal was to be able to type only and get to the OWA logon form. In order to do that the deny rule with the redirect was created as mentioned in Tom’s post “Clever Way to Redirect OWA Users Who Can’t Remember to Include /Exchange in the Path” but after typing the path we got to an endless attempt to access the page and it times out.


Since the traffic from the outside was encrypted, we decided to use HTTP Watch to understand why this behavior was happening. Here it is the result:



Notice that we have tons of HTTP Redirect 302 and this list goes on and on until it times out, in other words: we have a loop right there.




The catch for this loop is that the deny redirect rule had one extra character in the paths as shown below:




The flowchart below explains why this loop was happening and the problem with the asterisk (*) in this case:



By having the asterisk in the deny rule, the real OWA Publishing rule never had a chance to be processed and therefore we had this loop. To resolve the problem we changed the path and remove the asterisk and the path looks like this:


As you see, a simple detail that made a huge difference.

Skip to main content