Nearly all organizations that have deployed any version of Exchange now recognize and understand that allowing Port 80 access from the Internet directly into any Exchange Server is not exceptionally secure, and is therefore not desirable. I personally will not deploy Exchange for any of my customers unless they publish Exchange to the Internet using a hardware appliance or software application such as Microsoft’s TMG Server. In addition to pre-authenticating end user credentials, TMG can also be used to perform HTTP redirection to make accessing OWA easier for your end users.
Richard Hicks has a very good blog explaining how TMG can be used to perform HTTP redirection that can be found here. His blog explains a couple different alternatives to configure redirection, but I prefer to use the “Deny and Redirect” method. I recently ran into a situation where I configured TMG to use this method and it simply would not work. My intent was to change the URL my OWA users needed to enter in order to make their lives easier. I used the “Deny” method that Richard explains in his blog and redirected requests for http://mail.test.com to https://mail.test.com/owa. Even though I had created the “Deny and Redirect” rule correctly, the redirection would not work correctly.
In this case, it turned out that IIS had unintentionally been installed on the TMG Server. Because IIS had been installed, IIS was taking control of Port 80 thereby causing my Port 80 redirect within TMG to fail. I mention that IIS was unintentionally installed, because my customer never intended to install any IIS component. Researching this further, I discovered that my customer installs the .NET Framework 3.5.1 on all of their production servers running Server 2008. Part of the .NET Framework 3.5.1 installs HTTP Activation. Installing the HTTP Activation subset of the .NET Framework installed enough IIS components to take control of Port 80 and prevent my TMG redirection rule from executing correctly. See the following screen shot:
To resolve my issue, I uninstalled HTTP Activation, which allowed me to uninstall IIS. With IIS removed from the server, the TMG Port 80 redirection rule now works without issue. Note that uninstalling IIS will require a reboot, so plan accordingly.
Richard Hicks has a very good blog explaining how TMG can be used to perform HTTP redirection that can be found here. His blog explains a couple different alternatives to configure redirection, but I prefer to use the “Deny and Redirect” method. I recently ran into a situation where I configured TMG to use this method and it simply would not work. My intent was to change the URL my OWA users needed to enter in order to make their lives easier. I used the “Deny” method that Richard explains in his blog and redirected requests for http://mail.test.com to https://mail.test.com/owa. Even though I had created the “Deny and Redirect” rule correctly, the redirection would not work correctly.
In this case, it turned out that IIS had unintentionally been installed on the TMG Server. Because IIS had been installed, IIS was taking control of Port 80 thereby causing my Port 80 redirect within TMG to fail. I mention that IIS was unintentionally installed, because my customer never intended to install any IIS component. Researching this further, I discovered that my customer installs the .NET Framework 3.5.1 on all of their production servers running Server 2008. Part of the .NET Framework 3.5.1 installs HTTP Activation. Installing the HTTP Activation subset of the .NET Framework installed enough IIS components to take control of Port 80 and prevent my TMG redirection rule from executing correctly. See the following screen shot:
To resolve my issue, I uninstalled HTTP Activation, which allowed me to uninstall IIS. With IIS removed from the server, the TMG Port 80 redirection rule now works without issue. Note that uninstalling IIS will require a reboot, so plan accordingly.
THANKS SO MUCH!! I couldn’t figure out why my port 80 traffic wasn’t working!