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:
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)
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”).
STEP4: Edit the URL rewrite rule.
Under Action:
In the end you should be left with something that looks similar to this;
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).
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.
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.
Roop Sankar Bagepalli
Senior 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.