Part 4: IIS ARR as a Reverse Proxy and Load balancing solution for O365 Exchange Online in a Hybrid Configuration

Based on the feedback I received it looks like our readers enjoyed the previous set of articles (Part 1, Part 2, and Part 3) that were published about IIS ARR and because of that, the pirates Arrr!!! back with another article on how to use IIS ARR for O365 Exchange Online Hybrid configurations.

We have many customers who are running Hybrid with O365 today or are planning to sign up to O365 and coexist in a Hybrid configuration, and this article was written to help those customers effectively use or plan for IIS ARR as a Reverse Proxy solution.

As you may or may not know, if you use TMG in a hybrid configuration with Exchange Online, it is not supported to have TMG performing any pre-authentication against ADFS, Exchange Web Services (EWS) or AutoDiscover. So, when you are in an Exchange Hybrid Configuration, out of a total of five services we can only perform pre-authentication against two of available services (Outlook Anywhere and OWA), and this is not even considering the web traffic for Lync on-premises and Lync Online, which should not be pre-authenticated either.

When you look at it like this, if you read the previous articles that describe what IIS ARR offers, these limitations should lead you to conclude that IIS ARR is a great solution as it can provide both Reverse Proxy and L7 Load Balancing capabilities for your O365 Hybrid Configuration.

When an organization is setup as an Exchange Hybrid we can break down the traffic into two types ie: Inbound Traffic and Outbound Traffic. We are going to use these terms to explain how to control these two types of traffic in a Hybrid Scenario.

Illustration of the setup:

Inbound Traffic (Internet/O365 –> On-Premises)

When we refer to Inbound Exchange Traffic, from the Internet to on-premises, it usually means traffic for the usual Exchange clients such as Outlook Anywhere, EAS, OWA and EWS (users whose mailboxes are still on-premises). However in Hybrid scenarios we have additional requests for the Security Token Service (STS), or ADFS Proxy Servers by another name. Hence when configuring IIS ARR for inbound traffic we have to make sure that we add the necessary configuration required for the STS.

STEP1: Follow the earlier articles (here, here and here) which explain how to create the Web Farms and their corresponding URL Rewrite rules for the Exchange Services (Outlook Anywhere, OWA, EAS, AutoDiscover etc). For this example I have chosen the simplest implementation described in the previous blog posts (Option1) for the Exchange traffic.

STEP2: Create a new Web Farm for your STS endpoints (sts.roopdemo.co.uk in my example) and add each of your ADFS Proxy servers. This assumes that you have not setup any network load balancing between the ADFS Proxy servers, which is fine because we’ll be making use of IIS ARR’s load balancing capabilities to achieve load balancing and high availability of the ADFS Proxy servers.

STEP3: Configure the properties of the Web Farm (sts.roopdemo.co.uk)

1. Caching–> Disable Disk Cache
2. Health Test: There is no Health Check URL for ADFS and thus we need to create one so that IIS ARR can test for service availability of the ADFS service and make appropriate decisions in the event of a failure.
   1. Log on to one of the ADFS Proxy servers and create a HealthCheck.txt file on the ADFS Proxy server (in my example I do this at the root of the web site).
      1. On the ADFS Proxy server, open IIS Manager –> Default Web Site –> Explore

      2. Create a text file named HealthCheck.txt with the word Healthy in it.
      3. Repeat the above steps on all the ADFS Proxy servers.
   2. To verify that the HealthCheck.txt file renders properly, open the file in a Web browser.

   3. Once this is working, in IIS Manager expand the server node and select the sts.roopdemo.co.uk server farm.
   4. In the Server Farm pane, double-click Health Test.
   5. On the Health Test page, enter the following details:

      Make sure you enter the Healthy in the Response match box (response match is an optional test that searches the body of a response and looks for an expected string. Since the HealthCheck.txt file contains the word “Healthy,” the response match test will look for the word “Healthy”).

   6. Click Apply and hit “Verify URL Test” (it should come back with a Pass).
3. Load Balance–> Choose “Least current request”. Here we are making use of IIS ARR’s L7 load balancing capabilities, to effectively load balance the ADFS traffic between the ADFS Proxy servers.
4. Proxy–> Change the below two values. The actual value for these settings may need to be tweaked for your deployment, but these usually work well for a start.
   1. Time-Out: 300 seconds
   2. Response Buffer threshold: 0
5. Routing Rules - Uncheck “Enable SSL Offloading”.
6. Server Affinity - No changes required.

STEP4: Edit the URL rewrite rule.

1. You should see two URL Rewrite rules created (these were created when you selected “Yes” at the end of Server Farm creation)
2. Delete the one for HTTP(as shown below).

3. Open the properties of the newly created STS URL Rewrite Rule and make the changes shown below.

   Under Action:

In the end you should be left with something that looks similar to this;

Outbound Traffic (On-Premises –> O365)

When your organization is in a Hybrid configuration there is of course web traffic flowing from your on-premises environment to the O365 services and this traffic needs to be controlled. Most organizations don’t allow traffic that is destined to the internet, go directly out from the end-users workstation. Instead all internet based traffic would be first sent to a Web Proxy (installed on-premises) where some form of filtering would take place (based on corporate policy) and only then would the requested page/content on the internet be accessible. Thus keeping this situation in mind we are going to use the IIS ARR server to filter or allow only traffic to O365 URL’s.

By performing the below steps we are going to configure IIS ARR as a Forward proxy for all the Outbound traffic.

We’ll not be creating any Web Farms here, as all this traffic is going outbound. However we’ll be creating various URL Rewrite Rules to control what requests/web queries are being sent externally.

Follow the below steps;

STEP1: Create URL Rewrite rules for each of the O365 services.

1. In IIS Manager –> Server object –> URL Rewrite à Add Rule(s)
2. Select, Inbound Rules –> Blank Rule
3. Name –> O365_General_URLs (you can give it any name you like)
4. Pattern –> *
5. Conditions
   1. Logical Grouping –> Match Any
   2. Click, Add and enter a {HTTP_HOST} for every URLs/FQDNs from the below link.

      Office 365 URLs and IP address ranges

      http://onlinehelp.microsoft.com/Office365-enterprises/hh373144.aspx

      Note: Under Logical Grouping make sure you select Match Any.

   3. Under Action add the values as shown below.

      What we are doing above is providing back-references to the Rewrite URL. Back-references to Condition Patterns are identified by {C:N} where N is from 0 to 9; back-references to Rule Pattern are identified by {R:N} where N is from 0 to 9. Note that for both types of back-references, {R:0} and {C:0}, will contain the matched string.

      So for example, if any user tries to access https://portal.onmicrosoft.com/login , then the URL is broken down as shown below.

      {C:0} –> portal.onmicrosoft.com

      {R:0} –> login

      This is then evaluated by IIS ARR against the “Match URL” and “Conditions”. If it passes both, then it is rewritten as https://{C:0}/{R:0}, which is effectively the same URL. As we have many conditions to match against, using back-references (which is nothing but a variable) we can easily check to see if a URL is allowed and take the appropriate action i.e.: block it or forward it as is.

   4. You should now have a URL Rewrite Rule which should look like the below.

       

STEP2: Now repeat the process to add the Exchange Online URL’s. Note that the exceptions for Exchange Online have already been listed in the O365_General_URLs. However you can create this URL Rewrite Rule for ease of management purposes i.e.: if there were any new URL’s in the future for Exchange Online then all you need to do is add those new URL’s to this URL Rewrite rule.

STEP3 (Optional): If your organization also has Lync Online then create a URL Rewrite Rule and repeat the above process to add the exceptions.

So in the end you should see something similar. In my lab I have also configured Lync Online and thus you would see additional web services like meet.roopdemo.co.uk, dialin.roopdemo.co.uk etc.

Components involved in Inbound Web Traffic:

Components involved in Outbound Web Traffic:

That is it!!!.....you now have a solution that you can be used for your O365 Exchange Online Hybrid configurations.

Additional Information 1

If you want to lock down the protocols allowed by IIS ARR within a single URL Rewrite rule then you can write a Regular Expression as below. This is a much better control of the web request that are being forwarded to the CAS servers, as opposed to a wildcard (*). In the example below, within my URL Rewrite Rule for mail.roopdemo.co.uk, I have added the below Pattern which would thus only allow the below mentioned protocols/services.

Additional Information 2 – Bonus Time!

Recommendations for sizing the IIS ARR servers:

There is currently no specific guidance published for sizing of IIS ARR servers, however you can use the sizing guidance for the TMG servers as a starting point. The IIS ARR servers are only performing URL Filtering and thus the guidance shown below should be ideal.

In summary, we have seen that IIS ARR server (or server farm) can act as the ingress and egress point for all your O365 Hybrid web traffic. This thus makes IIS ARR act like a traffic controllerfor all the corresponding traffic and hence provides a better management experience for the admins. For all inbound traffic, IIS ARR provides a great Reverse Proxy solution, but it also natively provides a L7 load balancing solution. So you don’t have to invest in 3^rd party HLB’s and in effect reduce the total overall cost of implementing an O365 Hybrid solution.

My heartiest thanks to Greg Taylor (Principal PM Lead) for his help with reviewing this article.

Good luck and feel free to post comments and questions if you have them.

Roop Sankar Bagepalli
Senior Premier Field Engineer, UK