Warning: All the instructions in the top hits of google for setting up Exchange 2013 HTTP redirection are incomplete, incorrect or both. The goal of this article is to point out why, followed by providing proper reliable instructions worthy of your time.
The bad and why:
– Microsoft’s instructions don’t explain how to ‘undo’ the redirect setting inherited to the subdirectories or the need to re-check SSL on subdirectories. Here is the link so you know what I’m talking about incase you already read it (don’t actually use): https://technet.microsoft.m/en-us/library/aa998359(v=exchg.150).aspx
– The majority of other blogs out there have incomplete instructions and may leave many of your precious IIS settings in an unstable / non-default state.
How I determined the correct settings: I recorded the default ‘HTTP Redirect’ and ‘Require SSL’ settings of every single IIS subdirectory on a freshly installed Exchange 2013 server in order to determine the native default settings. This is critical because these native default settings need to be restored after the ‘top level’ Default Website and Exchange Back End websites are modified.
Complete instructions (written using Exchange 2013 CU7):
Default Website > SSL Settings > uncheck Require SSL
Exchange Back End > SSL Settings > uncheck Require SSL
Default Website > HTTP Redirect
click “Redirect requires to this destination”
enter /owa or https://mail.hostname.com/owa
Check “Only redirect requests to the content in this directory (not subdirectories)
Status code: “Found (302)”
Exchange Back End > HTTP Redirect
click “Redirect requires to this destination”
enter /owa or https://mail.hostname.com/owa
Check “Only redirect requests to the content in this directory (not subdirectories)
Status code: “Found (302)”
– I set the redirect to /owa rather than entering the entire URL
– Unchecked redirect on all virtual directories below Default Website
– Check SSL required on all virtual directories below Default Website, except PowerShell which should have require SSL unchecked.
– Unchecked redirect from all Exchange Back End virtual directories except: Exchange, Exchweb, and Public which redirect to /owa out of the box by default and should be left as redirect to /owa. Note: it’s possible Public does not redirect out of the box on CU8 – need to verify on a fresh CU8 install.
– Check SSL required on all virtual directories below Exchange Back End, except Rpc and RpcWithCert which should have require SSL unchecked.
– Found that SSL needs to be unchecked on both owa virtual directories, below Default Website and Exchange Back End otherwise the OWA redirection does not function.
Next: If you don’t have an SSL certificate yet, here are steps to setup an SSL cert on Exchange 2013.
Thanks! This worked for me.
Exchange Server 2013 CU12, 15.0.1178.4
My impression of Exchange+IIS configuration is a castle of cards. Touch anything and the whole thing comes tumbling down :-/
This is one of the best blog I have came across.
These settings broke autoconfigure both internally and externally. Just want to leave a word of caution to backup any existing settings before applyying any of these settings.
Hi, sorry to hear you had issues. What cumulative update of Exch 2013 are you running? Are you positive you applied the settings exactly as described? The settings outlined in this post have worked for me as well as several other commenters in the past. What was the resolution to fix autoconfigure/autodiscover? Thanks!
A couple of notes (verified in Exchange 2013 CU13 unmodified install):
“Check SSL required on all virtual directories below Default Website, except PowerShell which should have require SSL unchecked.” <– PowerShell AND Rpc should have Require SSL unchecked
"Note: it’s possible Public does not redirect out of the box on CU8 – need to verify on a fresh CU8 install." <– Public does redirect out of the box.
"Unchecked redirect from all Exchange Back End virtual directories except: Exchange, Exchweb, and Public which redirect to /owa out of the box by default and should be left as redirect to /owa." <– I noticed that before making any changes, Exchange, Exchweb, and Public all had forwards to /owa enabled. When I was trying to restore those forwards, I noticed that any change I made in those three sites also caused changes to the settings of the owa site. The owa did not have any forward defined before, but after making changes, now Exchange, Exchweb, Public AND owa have forwards set to /owa. If I tried to remove the forward from owa, it would also remove it from Exchange, Exchweb, and Public. So I left owa with a forward to /owa, even though it wasn't there before and it doesn't make sense for owa to forward to itself. Anyway, it still worked with that confusing forward.
I have to followup on this post because I don’t want to leave anyone misinformed:
“Unchecked redirect from all Exchange Back End virtual directories except: Exchange, Exchweb, and Public which redirect to /owa out of the box by default and should be left as redirect to /owa.”
So in my previous post I said that you couldn’t change the redirect in Exchange, Exchweb, and Public, without it also affecting the owa site. I also said that I left all four with the /owa redirect, even though the owa site did not originally have a redirect. I also said that it still worked using this setup.
Well, I was only testing the landing page (i.e. the login page) for Outlook Web Access, and that was indeed still working. But after actually logging in later, the page would be broken (pop-up box asking for login credentials again).
In short, I had to REMOVE the redirect for Exchange, Exchweb, Public, and owa (remember that it is all or nothing between these four, and any change made to one affects all). Since then, my users have been using the Outlook Web Access page now for several days with no apparent problems.
If anyone can figure out how to enable the /owa redirect under the Exchange Back End for the Exchange, Exchweb, and Public sites, WITHOUT also enabling the /owa redirect for the owa site, please post a response here letting me (us) know how you managed it!
===========================================
So below is my revised list of notes regarding your post (for Exchange 2013 CU13):
===========================================
“Check SSL required on all virtual directories below Default Website, except PowerShell which should have require SSL unchecked.” <– PowerShell AND Rpc should have Require SSL unchecked
"Note: it’s possible Public does not redirect out of the box on CU8 – need to verify on a fresh CU8 install." <– Public does indeed redirect out of the box, however see next note regarding Public and Exchange and Exchweb…
"Unchecked redirect from all Exchange Back End virtual directories except: Exchange, Exchweb, and Public which redirect to /owa out of the box by default and should be left as redirect to /owa." <– Exchange, Exchweb, and Public should NOT have the /owa redirect either, because the owa site will not work correctly with the /owa redirect enabled, and it does not seem to be possible – as far as I am aware – to enable the /owa redirect on Exchange, Exchweb, or Public without it also automatically enabling for the owa site.
Hi,
We have co-existence of exchange 2010 and 2013 in single site. On newly built exchange 2013 servers, whenever we are trying to access legacy mailbox from exchange 2013 OWA, it opened but in freeze mode. We are unable to do anything. I tried to open from local host too and different-2 browsers but no luck.
please help
Hi Manjeet,
You need to have a working hostname/URL for legacy Exchange 2010 OWA, this could be https://legacy.YourExternalDomainName.com/owa. The hostname will need to be included in your SSL Certificate, in this example, legacy.YourExternalDomainName.com, or you need to be using a wildcard certificate. Reason: if a users mailbox is on Exchange 2010 and they connect to the Exchange 2013 OWA URL, Exchange 2013 will redirect the browser to Exchange 2010 OWA URL. So you need a fully functional 2010 OWA, that you’ve tested and confirmed is functioning. Also the OWA external URL in Exchange 2010 will need to be set to the correct and working URL for Exchange 2010 OWA, because Exchange 2013 reads that value when it’s performing it’s browser redirect.
Hi Chris,
thanks for suggestion. my issue has been fixed and now working fine. it was not the case of redirection because we are using the same OWA URL. Issue was with our DR server where OWA URL was not working and all Exchange 2013 requests were going there. I just update the OWA virtual directories and everything was fixed.
thanks again.
Great job. This site deserves a bookmark and an exclusion from ABP. Thanks!
Thanks Marco, I appreciate your compliments!
Great guide, clear and concise. I was able to finally get everything working with this.
Thanks!
I was following another guide and changed many of my redirects. Now outlook won’t connect. What are the default paths for the (Default Web Site) aspnet_client, Autodiscover, ecp, EWS, mapi, etc. as well as the (Exchange Back End) sites?
Well, that’s what happens when you use *another guide* : )
Did using the settings I outlined fix the issue, that may take care of it. I think your Outlook connection issue may not be related to changes in IIS. Try Microsofts Remote Connectivity Analyzer, Outlook tests to gather more information. Also you can generally lookup and find the default IIS Exchange 2013 settings I’ve done so in the past (I may eventually post them). If you need more help let me know.