Application Request Routing and URL Rewrite – PART 1(Server Farms)

Application Request Routing and URL Rewrite – PART 1(Server Farms)

Rate This
  • Comments 6

In my previous blogs I had mentioned how we can use URL rewrite without ARR in picture. In the next series of upcoming blogs I will be discussing how we can leverage ARR and URL rewrite with ARR.

ARR is an out of band module available for IIS 7.x and onwards.

ARR can be used for below purposes.

1) As a load balancer when you want to load balance requests between multiple servers.

2) As a reverse proxy where your web servers are hidden from the internet world.

3) It can also be used for platform provisioning and application provisioning(by this I mean keeping configuration and features installed on top of IIS in sync between multiple servers) with the help of web deploy(which is famously know as web farm framework WFF). WFF is not tested completely from IIS 8 and onwards.

In this series we will discuss 1) and 2). First we will concentrate on how we can use ARR as a load balancer.

ARR as a load balancer

Before going ahead and using ARR as a load balancer. Let’s get familiarized with the options present in the ARR server farms UI which will help us during our discussion.


Below are the important options which we need to familiarize ourselves with when we want to use server farms or ARR as a load balancer.

1) Caching

2) Health Test

3) Load Balance

4) Monitoring and Management

5) Proxy

6) Routing rules

7) Server Affinity



This is similar to your IIS caching where you have the above mentioned options. This option will help you in caching content received from the backend server when the content has not been changed.

Element Name


Memory cache duration (seconds)

Enter the length of time, in seconds, that you want cached content to be stored. The default value is 60 seconds.

Enable disk cache

Select this check box to use your configured disk cache locations. By default, ARR caches content to the primary disk cache after it is configured.

Enable request consolidation

Select this check box to configure the request consolidation feature. Enabling request consolidation reduces the number of requests when streaming live content. By default, this feature is disabled.

Query string support

Select how you want to handle query string values from the following options:

  • Ignore Query String
  • Do Not Cache
  • Include Query String

Load Balance:


Over here you can specify the algorithm you want to use to perform load balancing and based on what criteria the incoming requests should be split between your web servers. The options present are all standard algorithms and you can find info about these algorithms over internet about how they work. Below are the available algorithm options about load balancing and a brief introduction about them.

  • Weighted round robin – Distributes traffic based on the number of incoming requests and their normalized weight. Each server can receive the same distribution of requests or a custom distribution.
  • Weighted total traffic – Distributes traffic based on the size of the requests and responses in bytes. Requests are routed so that the amount of data is load balanced. In an even distribution, the server with the least amount of data will receive the next request.
  • Least current request – Distributes traffic based on the current number of HTTP requests between ARR and each of the application servers. Requests are routed to the server with the least number of current HTTP requests.
  • Least response time – Distributes traffic based on the fastest response time from the servers, which enables the server to respond most quickly.
  • Server variable hash – Distributes traffic based on a hashed value of a server variable.
  • Query string hash – Distributes traffic based on the hashed value of the query string value. When more than one query string name is specified, the concatenated string of the corresponding query string value is used for the hash.

· Request hash – Distributes traffic based on the hashed value of the configured server variable or URL. For example, if the server variable is QUERY_STRING, the hashed value is based on the names in the request query string.



I forgot to include explanation for Reverse rewrite host in response headers in the image while creating it.

Reverse rewrite host in response headers: This option might not be of much value over here but its a very important setting while having reverse proxy. Imagine the internet exposed url is and you have the backend servers contoso1 and contoso2. consider an example where you have a redirect status set and in the response location tag is set to http://contoso1/redirectedpage.aspx in web server in respect to the request forwarded from ARR server and this has to be notified to the end client. the client doesn't know who contoso1 is. so before sending the complete response to the client, the ARR server rewrites the host name in the location tag as

Routing Rules:


This is pretty much self-explanatory and you will select “Use URL Rewrite to inspect incoming requests” option to use URL rewrite rules to evaluate requests that come through your server.

Another important option over here is Enable SSL offloading- if you select this option even though the requests from client to ARR server will be over https but while forwarding the requests to backend servers this will happen over http.

Requests with the following extensions are not forwarded: This is a very rarely used but a very good feature which helps you in improving performance. if you specify *.jpg, then it means that any request for .jpg image file will not be sent to the backend server. you can keep the static content like images on ARR server itself. This will add a condition in your rule. you can add this condition manually in your inbound rule as well. the condition will look like below.


Requests with the following patterns are not forwarded: This one is similar to the one mentioned above. when you have contents like templates, images or static content which wont change often then you can keep the copy of it in ARR server itself and then choose not to forward these request and process these request locally on ARR server. I can choose to ignore all the requests containing images in the path from being forwarded. you can manually add such a condition in your inbound rule as well and it will look like below.


Server Affinity:


Client affinity: People might be familiar with the name “sticky sessions” available in most of the hardware load balancers. This option provides the same feature in IIS. When you want the requests to be load balanced to the same server where the first request from the client was routed to for the whole session, you can use the client affinity feature over here.

This feature is advantageous where in your session state is ‘in-proc’ and not available outside the worker process.

Host Name affinity: imagine you have multiple hostnames for a site. based on the hostname used you can decide the affinity. Also if you have 4 servers for load balancing you can control the number of servers the requests can be routed if it comes with a specific hostname.


Monitoring and Management:


This will be your load balancer dashboard where you can monitor the health status and the request statistics, also how the load balancing is happening.

Creating sample to demonstrate load balancing by creating server farm in ARR

Scenario: Let’s consider the scenario where in we have two backend web servers’ and and one ARR server where we want to load balance the requests for the site “” between the two servers.

To achieve the above requirement we have two follow two simple steps.

1) Creating a server farm which will be a container for these two servers

2) Creating URL rewrite rules to monitor the incoming requests and route it accordingly

Creating a server farm:

Creating a server farm is a two-step simple procedure as below.

1) Right click on server farms-> Create new server farm


2) Enter a friendly farm name


3) Add the server which you want to include for load balancing. Over here in our scenario we have 2 servers contoso1 and contoso2


Creating URL rewrite rules for your farm:

After creating the farm 50% of the task is done. Now we will have to configure URL rewrite rules to monitor the requests and route it accordingly. When you create a server farm ARR will prompt you asking if it should create a URL rewrite rule for you. Let’s click on No for that. I will take you through the manual steps for creating the rule.

1) Make sure under routing rules at the server farm level you have the “USE URL REWRITE to inspect incoming requests” option checked.


2) When you are using ARR for either Load balancing or as reverse proxy the URL rewrite rules should be created at the server level. Go to URL Rewrite at the server level.


3) Add rule-> Inbound rules ->Blank rule.


4) I have already explained about the sections in inbound rules and regular expressions in my previous blog. So over here pattern would be ‘.*’ i.e, anything and a condition stating that this rule should be executed only when the hostname or HTTP_HOST is, action would be “Route to server farm” and under action properties select the appropriate server farm and specify the REQUEST_URI which we have stored as {R:0} from the pattern section in the URL.

The rule will look like below.



5) Click on Apply and you are good to go for testing.

Hope this helps. In next part of my upcoming blog I will discuss how we can use ARR as reverse proxy and how we can go through the troubleshooting if we are facing any issues and the tools that we can make use of.


Leave a Comment
  • Please add 1 and 3 and type the answer here:
  • Post
  • In your example, you have 2 webservers: and

    However you provided 2 application servers with only contoso1 and contoso2.

    How does the ARR find following?

    contoso1 ->

    contoso2 ->

  • @Ted: i have mentioned the FQDN of the server and in the screenshots that i have put in i just entered the name of the servers(it can be either FQDN or just the name)

  • How would you configure the same setting of https?

  • @Nasir: In the Scheme drop down you just need to select HTTPS if you want to route the requests over https to the backend servers. And in the front end for the requests to listen over https bind the appropriate external certificate to the Default Website running on the specific IP and port 443.

    Also one more thing to take care of is we need to make sure that if the certificates of the backend server are internal then you need to make sure that the issuers of the certificate are added to the trusted issuers list certificate store in the ARR server

  • Hi Chiranth,

    Actually I have an F5 load balance which is actually a device not a server

    Two ARR server with a shared configuration.

    Two App server with a shared configuration connected to the ARR web farm.

    I have bind both 80 and 433 to my web application with appropriate domain but the problem is that I am only able to access my application using port 80 and not port 433.

    When I try to access the site using port 443 it gives the following error

    "An error occurred during a connection to (Domain). SSL received a record that exceeded the maximum permissible length. (Error code: ssl_error_rx_record_too_long)

    The page you are trying to view cannot be shown because the authenticity of the received data could not be verified."

    Also please advice what is the best practice to install SSL certificate,ARR server or the the f5 load balancer which is actually a physical device.

    I have very little prior experience working in IIS but never worked on multi-tier model. I would be glad if you can guide me through the steps to solve the above errors and problem.

    I am on my own here and I am trying from last 5 days but still not able to resolve the problem.


  • Hi Nasir,

    ssl_error_rx_record_too_long means there is some issue with the certificate chain.

    Step 1. Make sure from the ARR server you are able to browse the backend site over HTTPS without any error or warning in IE using the same hostname as you have in the server farm(for eg, like a cert name mismatch or cert is not trusted)

    Step 2. Make sure the certificate chain is installed properly on the backend server. For eg: if you have got a certificate issued to and the issuer or intermediary CA is godaddy intermediate and root CA is godaddy main. you will be able to see this when you open the certificate and go to certification path tab, the one present at the top of the list is the root ca and the ones in between are intermediary ca's. Make sure the intermediary ca's of the certificate on the backend severs are installed in the intermediary certificate store of local computer in mmc of the backend servers as well as the ARR servers and root ca is present in trusted certificate store of local computer in mmc of the backend servers as well as the ARR servers.

    Step 3. Also follow step 2 for the certificate binded on ARR server and make sure the certificate chain is properly installed on the ARR server and also the client certificate store.

    Out of the note we are discussing we can also follow a approach so that the front end communication between client->NLB->ARR server can be over https and the requests to the backend servers can be offloaded to http as the backedn servers are not exposed outside.

    please reply back in case of any queries.

Page 1 of 1 (6 items)