Browse All Articles
> Exchange 2010: getting ERR_TOO_MANY_REDIRECTS error
REDIRECT LOOPS IN EXCHANGE 2010
There is an issue in IIS 7 and 8, where if you turn on redirection for the default web site in the UI, it also turns it on for all of the virtual directories. This will cause attempts to log into Exchange using OWA or Activesync or any other web service to go into a loop and create urls like this:
This in turn throws an error that looks something like this:
For the sake of anyone trying to search for this error message, let me type it out below:
The webpage at https://webmail.DOMAINC.com/owa/owa/owa/owa/owa/owa/owa/owa/owa/owa/owa/owa/owa/owa/owa/owa/owa/owa/owa/owa/owa/owa/forms/premium.StartPage.aspx
has resulted in too many redirects. Clearing your cookies for this site or allowing third-party cookies may fix the problem. If not, it is possibly a server configuration issue and note a problem with your computer.
It then shows the following Error code: ERR_TOO_MANY_REDIRECTS
So, what do you do about it?
The suggestion to clear the cookies will not fix this issue in this case. The problem is the Default web site is handling the redirect but so are the virtual directories. This causes them to stack and ultimately to send the connection into a loop where the stacking just keeps happening and when it gets about 22 levels deep, the server throws an error saying, "you can't do that".
You literally need to go back into IIS to uncheck the Redirect requests to this destination check box on every virtual directory.
Technically, you should never make changes in IIS directly on an Exchange server. So let me show you how replication should have been enabled in the first case and then how you should actually fix it using APPCMD instead of the UI.
Best Method to turn on HTTP Redirection for your Exchange 2010 Server.
First, launch an elevated command prompt (Run as Administrator) on the Exchange server.
Next, change directory to the Inetsrv directory:
From there you can run the following APPCMD command to enable redirection for your exchange 2010 server (replace the destination with your webmail URL:
appcmd set config "Default Web Site" -section:httpRedirect /enabled:true -destination:"https://www.domainc.com"
That's it. The Exchange Server is now enabled for redirection.
So, I already set my server using the UI in IIS, how do I unset it using the APPCMD?
Well, first of all, shame on you. You should never modify IIS on an Exchange server using the UI. It can cause inconsistencies between Exchange and IIS. If the commands are not available for what you need to do in Exchange Management Shell, and the web.config file is too intimidating for you (a little secret, it is too intimidating for pretty much everyone and should be modified with EXTREME caution), then you should do it using the APPCMD commands.
But enough public shaming. You can quickly turn off redirect for all of the virtual directories using the following commands from an elevated command prompt:
appcmd set config "Default Web Site/Autodiscover" -section:httpRedirect /enabled:false
appcmd set config "Default Web Site/ecp" -section:httpRedirect /enabled:false
appcmd set config "Default Web Site/EWS" -section:httpRedirect /enabled:false
appcmd set config "Default Web Site/Microsoft-Server-ActiveSync" -section:httpRedirect /enabled:false
appcmd set config "Default Web Site/owa" -section:httpRedirect /enabled:false
appcmd set config "Default Web Site/PowerShell" -section:httpRedirect /enabled:false
appcmd set config "Default Web Site/PowerShell-Proxy" -section:httpRedirect /enabled:false
appcmd set config "Default Web Site/Rpc" -section:httpRedirect /enabled:false
appcmd set config "Default Web Site/RpcWithCert" -section:httpRedirect /enabled:false
Last step is to reset IIS to make the changes take effect:
I can't state this enough, never use the IIS ui to make changes to IIS settings on an Exchange server. This is a highly preventable issue by obeying that one rule.
As far as setting redirects, you either want to manually set the redirects on individual virtual directories, or on just the Default Web Site, never on both. Hopefully this article will save you time and effort when dealing with this issue.