Introduction

Application Request Routing (ARR) is a proxy-based routing module that uses HTTP headers, server variables, and load balance algorithms to determine how to forward HTTP requests to content servers. The release of ARR 3.0 in July 2013 contains a few new features, as well as bug fixes. The following information describes the new features and how to use them, as well as general information about ARR 3.0

Support matrix

ARR 3.0 was tested and is supported on Windows Server 2008, 2008 R2, 2012 and 2012 R2. It’s available in an X86 version for Windows Server 2008, and an X64 version, which is supported on all the above platforms.

Installation

Microsoft recommends ARR to be install from within the Web Platform Installer module (WebPI). To install from WebPI, type ARR in the search box, and click the appropriate item to install it.

It’s also possible to install ARR by downloading the MSI package, but please note that installing it directly requires the administrator to perform several steps in a specific order (normally, WebPI manages that automatically). These steps are:

1. Stop IIS by running the commands net stop was and net stop wmsvc on an elevated command-prompt window

2. Install URL rewrite (v2)

3. Install Web Farm Framework (v1)

4. Install ARR (v3)

5. Install the External Cache module (v1)

6. Start the IIS services back, or reboot the server.

To download the ARR MSI, visit this page. To download the MSI for the other pieces, visit this page.

New features

ARR 3.0 was released in Beta in December of 2012, and included the following new features:

· Retries for URL Health Monitoring

· Web Socket Support

The final version (July 2013) also adds support for Session affinity opt-out. Here are the details about these features.

Retries for URL Health Monitoring

As part of normal farm management, ARR performs health-test for configured web servers, so that if a server in the farm becomes unavailable, ARR would not forward requests to it. Before version 3, health monitoring would mark a server as unavailable if it fails to respond a single time. This may impact availability in certain situations, because intermittent network or application errors could lead to a server being marked as unavailable when in fact it was.

To address that, health-monitoring can now be configured by the administrator to retry, and conclude that the server is unavailable only after a defined retry-count. By default, Health-monitoring will retry the check 3 times, and the administrator can change the value to a different one by editing the configuration in ApplicationHost.config.

The following article describes additional parameters that can be configured as part of health monitoring: http://blogs.iis.net/richma/archive/2010/12/14/application-request-routing-health-check-features.aspx

WebSocket Support

With the release of Windows Server 2012, IIS added support for using WebSockets. Since WebSockets requires special handling by proxies, ARR needed some changes to be able to support this feature. This allows ARR to distinguish between a regular HTTP request and a WebSockets request, and handle them correctly.

WebSocket support requires the WebSocket feature to be installed on IIS, but does not require any other configuration or action. Install the feature using the Server Manager Add Roles and Features, and once that is complete, ARR 3.0 will handle the requests appropriately. The new feature supports both plain (ws://) and secure WebSocket (wss://) requests and it can also provide SSL offloading for WSS requests.

Session affinity opt-out

An important part of load balancing is maintaining affinity. Maintaining affinity means that once ARR routes a request to a server, subsequent requests from the same client that are a part of the same session should go to the same server. To maintain affinity, ARR attaches a unique affinity session cookie to each new session, with the selected server stored in the cookie. Once a subsequent request from the same client arrives, ARR decodes the cookie, extracts the server name, and knows to route that request to the same server. Similar methods are employed by all commercial reverse proxies. Here’s an example of such a cookie:

The challenge with this mechanism is that a session cookie can exist indefinitely, and so if the client’s browser remains open, it will continue serving back the affinity cookie, and be continuously redirected to that same server. In an environment where many clients keep their browsers open for extended period of time, this could, over time, lead to an imbalance in client distribution.

To address this, ARR 3.0 allows web applications to opt-out of session affinity. To do this, an application would need to set a special response-header that signals to ARR to disable affinity for the application.

The special response header is Arr-Disable-Session-Affinity and the application would set the value of the header to be either True or False. If the value of the header is true, ARR would not set the affinity cookie when responding to the client request. In such a situation, subsequent requests from the client would not have the affinity cookie in them, and so ARR would route that request to the backend servers based on the load balance algorithm. Note that this behavior could have serious impact on session-sensitive application, so enabling this on a web application must be considered carefully.

Troubleshooting

To help troubleshoot potential issues, FREB (Failed Requests Tracing – formerly known as Failed Request Event Buffering) has specific events for WebSocket requests. The WebSocket protocol mandates that when a WebSocket connection is initiated by a client, the accepting server should reply with a 101 status code, along with a Sec-WebSocket-Accept key. In the event a connection is accepted, IIS’s WebSocket module will raise a FREB event titled WEBSOCKET_HANDSHAKE_SUCCESS. If there is a problem, a failed event will be raised. By setting the appropriate filters in FREB, you can capture and examine these events:

When enabling FREB, keep in mind that setting a trace for success-type events (such as 101 and 200 status codes) on a production server would result in a large number of events, which could increase the load on the server to unacceptable levels, and is therefore not recommended.

In addition, new performance counters that are specific for WebSockets have been added to Windows, and they are under the W3SVC_W3WP group in PerfMon:

Blog post by Erez Benari and Jenny Lawrance

When Christopher Bullock wrote about the certainties in life in his book The Political History of the Devil, he probably should have added a 3^rd certainty…that your certificates WILL expire and you’ll have to renew them. I think we can forgive that, as he wrote the book in 1726 and websites weren’t as popular as they are today. However, the topic of certificate renewal is one that certainly plagues the nightmares of every seasoned system administrator.

Ultimately, if you’re an efficient fellow, you can try to have all your certificate expire around the same date, or set reminders in Outlook to remind you about the upcoming expiration, but in reality, it’s the sort of things that tend to get missed even by the most experienced engineers. Even if you do get it right, or have your certificates automatically renew, there’s still the issue of certificate rebind. When an IIS site is configured for a certificate, it has to be re-bound when the certificate is renewed, and if you don’t perform this (by going to the site binding dialog, and selecting the new certificate from the certificate drop-down), you ARE going to get some nasty phone calls.

To make things easier, Microsoft has implemented a new helper mechanism in windows called Certificate Services Lifecycle Notifications. This mechanism is part of Windows 8 and Windows 2012, and it creates system events when certain certificate-related things happen. For example, when a certificate is about to expire (a day before expiration), an event with ID 1003 will be logged under /Applications and Services Logs/Microsoft/Windows/CertificateServicesClient-Lifecycle-System or /Applications and Services Logs/Microsoft/Windows/CertificateServicesClient-Lifecycle-User:

The details pane will show more info, such as the certificate’s subject name and thumbprint:

Other events that might be recorded as part of this mechanism are:

1. New certificate has been installed

2. Certificate has been renewed or replaced

3. Certificate has expired

4. Certificate has been deleted

5. Certificate has been archived

6. Certificate has been exported

Because these events are now logged, administrators can make use of them to help them take care of the other aspects of certificate management. For example, you can use Task Manager to trigger a task when one of these events occur, and the task can do whatever you need it to do, from a simple pop-up notification to the administrator all the way to complex code or scripts that can cure cancer on-queue. The following wiki article by Kurt Hudson details this mechanism and some of the things you can do with it:

http://social.technet.microsoft.com/wiki/contents/articles/14250.certificate-services-lifecycle-notifications.aspx

To take this a step further, the IIS team has implemented some new functionality in IIS 8.5, which is part of the upcoming Windows 2012 R2 release. This functionality is designed to take advantage of the same notification mechanism and automatically re-bind a certificate that has been renewed.

To make this happen, IIS can automatically register a task in the system’s Task Scheduler, and the task is keyed to trigger upon a certificate-renewal event (event ID 1001). When such an event happens (either when the administrator has manually renewed the certificate, or if it renews with Auto-enrollment), the scheduled task runs IIS’s command-line based tool APPCMD, and gives it the thumbprint of the old (expired) certificate and the thumbprint of the new one. Using these two parameters, APPCMD locates the websites which are bound to the old certificate and rebinds them to the new one.

As far as the user-interface goes, the IIS console now offers the following option, which allows the administrator to enable or disable this functionality:

The tasks created by this mechanism in Task Scheduler can be viewed by opening up Task Scheduler, and navigating to /Microsoft/Windows/CertificateServicesClient, and as you can see, it shows the parameters sent to APPCMD:

If you disable this function in IIS Manager, the task is deleted. This is a good opportunity to note that fiddling with the settings in this task or deleting it manually is not supported, and could have unpredictable results, so don’t do it.

With this feature, the process of certificate renewal can finally be put in the “fugget about it” pile. Simply setup your certificates to automatically renew with Autoenrollment, enable this feature on your IIS servers and go back to reading The Political History of the Devil.