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)
- Caching –> Disable Disk Cache
- 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.
- 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).
- On the ADFS Proxy server, open IIS Manager –> Default Web Site –> Explore
- Create a text file named HealthCheck.txt with the word Healthy in it.
- Repeat the above steps on all the ADFS Proxy servers.
- On the ADFS Proxy server, open IIS Manager –> Default Web Site –> Explore
- To verify that the HealthCheck.txt file renders properly, open the file in a Web browser.
- Once this is working, in IIS Manager expand the server node and select the sts.roopdemo.co.uk server farm.
- In the Server Farm pane, double-click Health Test.
- 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”).
- Click Apply and hit “Verify URL Test” (it should come back with a Pass).
- 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).
- 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.
- 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.
- Time-Out: 300 seconds
- Response Buffer threshold: 0
- Routing Rules - Uncheck “Enable SSL Offloading”.
- Server Affinity - No changes required.
STEP4: Edit the URL rewrite rule.
- You should see two URL Rewrite rules created (these were created when you selected “Yes” at the end of Server Farm creation)
- Delete the one for HTTP (as shown below).
- 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. Some organizations don’t allow traffic that is destined to the internet, to 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. This Web Proxy thus acts as a Forward Proxy for all internet (Exchange Online, Lync Online etc) based traffic. All this web traffic to the O365 service is encrypted using SSL.
The IIS team doesn't support IIS ARR as a Forward Proxy for SSL traffic.
Thus for such organizations, you would need to invest in a third party Forward Proxy application to allow end-users to access the O365 services (Exchange Online, Lync Online & SharePoint online).
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 controller for 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 3rd 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.
Senior Premier Field Engineer, UK
Updates
- 3/19/2014: Updated Outbound Traffic (on-premises to O365).