For a long time, ForeFront TMG (and ISA before it) has been the go-to Microsoft reverse proxy solution for many applications, including Exchange Server. However, with no more development roadmap for TMG 2010 a lot of customers are looking out for an alternative solution that works well with Exchange Server 2013.
The Windows team have added an additional component called Application Request Routing (ARR, or as Greg the pirate says, ARR!) 2.5 to the Internet Information Service (IIS) role, which enables IIS to handle reverse proxy requests. By using the URL Rewrite Module and Application Request Routing you can implement complex and flexible load balancing and reverse proxy configurations.
There are two options when implementing this solution and each have their pros and cons, which I'll cover in three posts. In this first post, we'll take a look at:
In the next 2 posts in the series, we'll cover the second option and some troubleshooting steps. The troubleshooting steps would also help you to verify if you have implemented the reverse proxy solution correctly.
Here's a diagram of the environment we'll use when discussing how to implement ARR.
TIP To make sure you're configuring and using the right network interface, rename the NICs to Internal and External.
Requirements: IIS ARRis supported on Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012. It is also supported on Windows Vista, Windows 7, and Windows 8 with the Web services features installed. Note that IIS ARR does not require IIS 6.0 compatibility mode.
Note: As with all such changes, we recommend that you test this in a non-production environment before deploying in production environment.
To install IIS with the ARR module on the server identifid as the Reverse Proxy:
If you don’t have internet access on the IIS ARR server, you can use the steps highlighted in How to install Application Request Routing (ARR) 2.5 without Web Platform Installer (WebPI).
This is the simplest way of implementing IIS ARR as a Reverse Proxy solution for Exchange Server 2013. This implementation requires a minimum number of SAN entries in your certificate and minimum number of DNS entries.
This set up assumes that all protocols (OWA, ECP, EWS etc) have been published with the mail.tailspintoys.com namespace.
On the Server Farm settings node make the configuration changes as detailed below:
In Exchange 2013 there is a new component called Managed Availability and it uses various checks to make sure that each of the protocols (OA, OWA, EWS, etc.) are up and running. If any protocol fails this check then an appropriate action is automatically taken. (This was just a very simple explanation as to what Managed availability is of course, but if you can take it, and want a more detailed understanding watch Ross Smith IV’s TechEd 2013 Session). We are going to leverage one of these checks to make sure that the service/protocol is available.
https://<fqdn>/<protocol>/HealthCheck.htm is the default web page present in Exchange 2013. These URL’s are specific for each protocol and do not have to be created by the administrator.
Configure the Health Test with the following settings:
Interval: 5 seconds
Time-Out: 30 seconds
Acceptable Status Code: 200
Time-Out: 200 seconds
Response Buffer threshold: 0
Note: Make sure the option “Stop processing of subsequent rules” is selected. This is to make sure that the validation process stops once the requested URL finds a match.
That’s it!!!! ....You are now all set and have a reverse-proxy-with-load-balancing solution for your Exchange 2013 environment!
Give it a try and see how it works. Make sure DNS for mail.tailspintoys.com resolves to your reverse proxy and try connecting a client. And if it doesn’t work, go back through the steps and see where you went wrong. And if it still doesn’t work, post a comment here, or wait for Part 3, Troubleshooting (so please don’t do all this for the first time in a production environment! Really, we mean it!).
Finally, here are a couple of additional changes we recommend you review and optionally consider making to your IIS ARR configuration.
We've spent time testing this configuration and found it to work as we hoped and expected. Note that support for IIS ARR is provided by the Windows/IIS team, not Exchange. That's no different than support for TMG or UAG (if you use either of these products to publish Exchange).
We would really appreciate any feedback on your implementation and/or any configuration where this doesn’t seem to work.
Keep your eyes peeled for the next set of articles where we’ll talk about slightly complex and interesting implementations of IIS ARR for Exchange 2013.
I would like to thank Greg Taylor (Principal PM Lead) for his help in reviewing this article.
B. Roop Sankar
Premier Field Engineer, UK
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.