Overview
This topic leads the reader through the steps to configure Application Request Routing to load balance HTTP requests to achieve high availability and scalability. The walkthrough also highlights a couple of core features on how Application Request Routing monitors the health of the content servers and affinitizes requests from a client to a content server.
Goal
To load balance HTTP requests across several content servers using Application Request Routing as shown below:

Prerequisites
This walkthrough requires the following prerequisites:
- IIS 7.0 on Windows 2008 (any SKU).
- Microsoft URL Rewriter Customer Technical Preview (CTP) 1.
- Microsoft Application Request Routing CTP1.
- Minimum 2 content servers with ASP.NET installed.
If URL Rewriter CTP1 or Application Request Routing CTP1 has not been installed, it is available for download at:
- URL Rewriter x86
- URL Rewriter x64
- Application Request Routing x86
- Application Request Routing x64
Another prerequisite is that the reader has defined and configured a server group using the steps outlined in Define and Configure an Application Request Routing (ARR) Server Group. Before proceeding with this walk through, the server should be configured like the diagram below:

Step 1 – Create URL rewrite rules
Provided that the server group has been created using the steps outlined in Define and Configure an Application Request Routing (ARR) Server Group, the next step is to create the URL rewrite rule to inspect the HTTP requests and route traffic to the server group in Application Request Routing.
To create URL rewrite rules via UI:
1. Launch IIS 7 inetmgr.
2. Select the root of the server:

Locate URL Rewrite Module icon under IIS group heading and double click on the icon.
3. To create an URL rewrite rule, under Actions, click on Add Rule… and enter the following values:
- Name: Load Balance
- Requested URL: Matches the pattern
- Using: WildCards
- Pattern: *
- Ignore Case: Checked

4. Since the Application Request Routing and the two sample sites, comicSite1 and comicSite2, are installed and created on the same server, we will have to add a condition so that the URL rewrite rule is only applied on the initial requests on port 80. Click on Add Conditions and click on Add…. Enter the following values:
- Condition input: {SERVER_PORT}
- Check if input string: Matches the pattern
- Pattern: 80
- Ignore case: Checked

5. Under Action, enter the following values:

Note that the server group alias, comicSiteServers, is referenced in the Rewrite URL, to indicate that the requests will be routed to the servers in comicSiteServers server group. In this case, all HTTP requests coming in on port 80 would be routed to the comicSiteServers server group.
6. Open a browser and send several requests to the default site on port 80.
7. To verify that the requests are being load balanced equally between comicSite1 and comicSite2, select the root of the server in inetmgr, double click on Application Request Routing icon under IIS heading, and select comicSiteServers server group to display the dashboard. The runtime statistics provide the visibility on how the traffic is being routed:

Step 2 – Configure health check monitoring
Application Request Routing monitors the health of the content servers in two ways:
- Via the live traffic
- Via an explicit URL testing
The live traffic testing is performed automatically when the requests are made to Application Request Routing. The explicit URL testing is an additional testing that can be used with the live traffic testing. In this section, the walkthrough guides through configuring the explicit URL testing.
To configure health check monitoring via UI:
1. The URL testing requires a specific URL to test. To satisfy this requirement, create a text file named healthCheck.txt using a notepad containing the sentence “I am healthy.”
2. Place the healthCheck.txt file at the root of comicSite1 and comicSite2.
3. Verify that the healthCheck.txt is rendering properly by opening the page via a browser. (ie. http://localhost:9000/healthCheck.txt for comicSite1 and http://localhost:9001/healthCheck.txt for comicSite2.)
4. On IIS 7 inetmgr, select the root of the server, double click on Application Request Routing icon under IIS heading, and select comicSiteServers server group.
5. Under Actions, under Server Group Management, click on Server Group Settings.
6. Select Health Check tab and change the following two properties under URL Test:
- URL: http://(server name or FQDN of ARR)/healthCheck.txt
- Response Match: healthy

Response Match is an optional testing to make sure that the body of the response contains the expected string. In this case, since healthCheck.txt contains the sentence “I am healthy.”, the Response Match will look for the word “healthy”.
7. Click OK to save changes.
8. To verify the functionality of healthy check monitoring, stop comicSite1 on port 9000. Since the Interval (seconds) value is set to 30 seconds, wait for 30 seconds for the next health check.
9. After waiting for 30 seconds, send several requests to the default site on port 80.
10. To verify that all the requests are going to the healthy server, comicSite2 on port 9001, refresh the dashboard in IIS 7 inetmgr by hitting F5. Note that the runtime statistics have been reset. This is by design. Verify that the runtime statistics are changing only for comicSite2. You may want to send additional requests and refresh the dashboard, as needed:

11. Health monitoring is also used to detect when an unhealthy server becomes healthy. To verify this functionality, start comicSite1 on port 9000. Again, since the Interval (seconds) value is set to 30 seconds, wait for 30 seconds for the next health check.
12. After waiting for 30 seconds, send several requests to the default site on port 80.
13. To verify that the requests are distributed evenly between servers, comicSite1 on port 9000 and comicSite2 on port 9001, refresh the dashboard in IIS 7 inetmgr. Note that the runtime statistics have been reset. This is by design. Verify that the runtime statistics are changing for both comicSite1 and comicSite2. You may want to send additional requests and refresh the dashboard, as needed.
Step 3 – Configure client affinity
Application Request Routing provides a client affinity feature which maps a client to a content server behind Application Request Routing for the duration of a client session. When this feature is enabled, the load balancing algorithm is applied only for the very first request from the client. From that point on, all subsequent requests from the same client would be routed to the same content server for the duration of the client session. This feature is useful if the application on the content server is stateful and the client’s requests must be routed to the same content server because the session management is not centralized.
To configure client affinity via UI:
1. On IIS 7 inetmgr, select the root of the server, double click on Application Request Routing icon under IIS heading, and select comicSiteServers server group.
2. Under Actions, under Server Group Management, click on Server Group Settings.
3. Select Affinity tab and change the following two properties under Client Affinity:
- Client affinity: check the checkbox.
- Cookie name: either use the default name or enter your own.

Application Request Routing uses a cookie to enable client affinity. The Cookie name above will be used to set the cookie on the client. That said, the client must accept cookie in order for the client affinity to work properly.
4. To verify that the functionality of client affinity, send several requests to the default site on port 80. Refresh the dashboard in IIS 7 inetmgr. Verify that the runtime statistics are changing either for only comicSite1 or comicSite2, but not both. Your client is affinitized to the site with the increasing runtime statistics. You may want to send additional requests and refresh the dashboard, as needed.
Step 4 – Draining connections
Draining connections on a server is a graceful way of taking the server out of the server group environment. It is more meaningful when the client affinity feature is in use because Application Request Routing will honor the existing sessions when draining connections. This is to say that when a client is affinitized to the server that is draining connections, the client will continue to be routed to the same server and therefore, there is no impact on the client. However, no new clients will be routed to the server that is draining connections.
To drain connections via UI:
1. Using the setup from Step 3 above, identify the server that your client is affinitized to. It should either be comicSite1 on port 9000 or comicSite2 on port 9001.
2. On IIS 7 inetmgr, select the root of the server, double click on Application Request routing icon under IIS heading, and select comicSiteServers server group.
3. Select the server that your client is affinitized to:

4. Under Actions, under Server Management, click on Drain Connections.
5. Click Yes:

6. To verify that the requests from your clients continue to get routed to the affinitized server, which is now getting drained, send several requests to the default site on port 80. Refresh the dashboard in IIS 7 inetmgr. Verify that the runtime statistics are changing only for the server that is being drained. You may want to send additional requests and refresh the dashboard, as needed:

7. To verify that the new clients are not being routed to the server that is being drained, remove the cookie set by Application Request Routing by closing and restarting the browser.
8. Send several requests to the default site on port 80. Refresh the dashboard in IIS 7 inetmgr. Verify that the runtime statistics are changing only for the server that is Available. More specifically, the runtime statistics for the server that is being drained are not changed. You may want to send additional requests and refresh the dashboard, as needed.
Summary
You have now successfully defined the rules in URL Rewriter and properties in Application Request Routing to enable a HTTP load balance scenario. For more advanced routing capabilities using Application Request Routing, refer to Using Application Request Routing.
Related Content
Comments