Using Application Request Routing as a Reverse Proxy for SharePoint

With the questionable life span of the Microsoft Forefront brand, the Application Request Routing module for IIS7+ serves as a replacement reverse caching proxy. In conjunction with the Web Farm Framework and URL Rewrite, the ARR, in some cases, can provide an alternative to licensed products, such as Microsoft UAG, for todays needs. This guide will walk you through creating an ARR server running Windows Server 2012 Core to proxy requests to a SharePoint 2010 server (with notes for SharePoint 2013).

To start, build a Windows Server 2012 installation using the Core install option. The core install option is ideal to reduce the attack surface of our reverse proxy and increase uptime via the way of a reduced patching scope.

Once the server is built, set the Network Adapter configuration via PowerShell:

Get-NetAdapter #To identify existing adapter(s)
Rename-NetAdapter -Name "Ethernet" -NewName "Internet"
New-NetIPAddress -AddressFamily IPv4 -IPAddress -PrefixLength 24 -DefaultGateway -InterfaceAlias "Internet"
Set-DnsClientServerAddress -ServerAddresses -InterfaceAlias "Internet"

Note that the DNS servers that the network adapter uses must resolve the SharePoint host names back to the SharePoint server(s)! If the client entry here resolves SharePoint host names back to itself, you may face repeated authentication prompts from the ARR server.

Next, rename the server and restart. You’ll note that we are not joining a domain here. Joining a domain is optional and may increase the attack surface of the server depending on network configuration. In addition, joining a domain is not a requirement for creating an ARR (or Windows NLB) farm!

Rename-Computer ARR01

When the server is back online, add the necessary Windows Features:

Add-WindowsFeature Web-Static-Content,Web-Mgmt-Service

Yep, only two features (well, it adds dependencies…)!

Next, we need to transfer the necessary bits to the server in order to install the Application Request Routing pre-requirements and patches.

#URL Rewrite 2:
Start-BitsTransfer -Source
#Web Farm Framework 1.1:
Start-BitsTransfer -Source
#Application Request Routing 2.5:
Start-BitsTransfer -Source
#External Disk Cache v1:
Start-BitsTransfer -Source
#External Disk Cache Patch:
Start-BitsTransfer -Source
#For IIS8 only, Application Request Routing hotfix:
Start-BitsTransfer -Source
#Application Request Routing hotfix for NTLM support:
Start-BitsTransfer -Source

We will install the bits the same order we downloaded them in:

rewrite_amd64_en-US.msi /passive
webfarm_v1.1_amd64_en_US.msi /passive
requestRouter_amd64_en-US.msi /passive
ExternalDiskCache_amd64_en-US.msi /passive
ExternalDiskCachePatch_amd64.msp /passive
requestrouter_amd64.msp /passive #IIS8 only

Next, you will need to transfer the SharePoint server SSL certificate with private key and certificate chain to the Application Request Routing server. Here’s a hint: You can use Start-BitsTransfer for that, too!

Export the SSL certificate from your SharePoint server with the private key to a PFX file. Copy the PFX to a location to transfer it from.

Start-BitsTransfer -Source

Next, we’ll import the certificate and certificate chain. If the certificate chain is not imported, we are likely to receive “502 Bad Gateway” errors when attempting to view SharePoint sites via SSL.

$certCollection = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2Collection

We must add each certificate to the appropriate store. This PFX only has two certificates in it, the Root Certificate Authority and the Wildcard SSL Certificate. When viewing the $certCollection object, the certificates are ordered in a zero-based index. We can access individual certificates based on this index.


Create two X509Store objects to add each certificate to. This example only requires the “MY” (Personal) and “Root” (Trusted Root Certificate Authorities). We will be adding them to the LocalMachine store.

$certStore1 = New-Object System.Security.Cryptography.X509Certificates.X509Store("Root","LocalMachine")
$certStore2 = New-Object System.Security.Cryptography.X509Certificates.X509Store("My","LocalMachine")



Next, we will want to manage the Application Request Routing server from a remote machine using IIS Manager. You will either need Windows Server 2012 with the IIS Manager installed, or Windows 8 with the IIS Manager for Remote Administration installed. The built-in IIS Manager included with Windows 8 does not allow for remote administration. To enable remote management on the Application Request Routing server, run:

sp HKLM:\SOFTWARE\Microsoft\WebManagement\Server EnableRemoteManagement -Value 1
Start-Service WMSVC
Set-Service WMSVC -Startup Automatic

This will flip the bit on the EnableRemoteManagement key, start the IIS Web Management Service, and set the service to automatically start.

Using IIS Manager, connect to the Application Request Routing server:


When prompted, enter the Administrator username (in the format of ARRSERVERNAME\Username) and password for the Application Request Routing server. Next, you’ll be prompted to download and install the features to match the server:


First thing is to edit the IIS Bindings of the Default Web Site, adding the SSL certificate that matches what is used on SharePoint.


The next couple of settings will modify the DefaultAppPool to not timeout or recycle. Using the IIS Manager, you can easily change these settings on the Advanced Settings and Recycling Conditions, respectively:



Optionally, this can be done from the Application Request Routing host via appcmd.exe:

C:\Windows\System32\inetsrv\appcmd.exe set apppool "DefaultAppPool" /processModel.idleTimeout:00:00:00 /commit:apphost
C:\Windows\System32\inetsrv\appcmd.exe set apppool "DefaultAppPool" /recycling.periodicRestart.time:00:00:00 /commit:apphost

Finally, before we get to creating the Server Farm, add the OptionalWinHttpFlag via PoweShell on the Application Request Routing host:

New-ItemProperty 'HKLM:\SOFTWARE\Microsoft\IIS Extensions\Application Request Routing' -Name OptionalWinHttpFlag -Value 72 -PropertyType Dword

Back in the IIS Manager, create a new Server farm named “SharePoint” (or anything you want it to be named).


Add all SharePoint servers that respond directly to end user requests to the new farm.


The Create Farm wizard will prompt if you want to create the appropriate URL rewrite rules. Unless you have an advanced configuration, just say yes here.

Click on the farm name in the left hand tree. Here you will see the options available to you to configure the farm. One thing to immediately note is the Server Affinity feature.


If you are using SharePoint 2010 or below, check Client affinity. If you using SharePoint 2013, this is not required, but consider its use if not using SSL offloading as renegotiation of an SSL session is expensive. Under the Routing Rules feature, disable SSL Offloading if you are not using it.

Implementation and testing of the ARR server is completely transparent to the user – because you don’t have to redirect user requests through the ARR prior to a production deployment in order to validate the configuration functions correctly. Modify your client’s hosts file (C:\Windows\System32\drivers\etc\hosts) with an entry similar to:

# ARRServerIP SharePointHostname sharepointwebapp

Next, from the client, navigate to the site. If everything loads, great! To validate that we are routing through our new reverse proxy, run Fiddler while browsing the site.

You’ll see entries from both SharePoint and the IIS ARR module in the request and response headers, like this:ARRFiddler

Here we see the X-Powered-By ARR/2.5 header as well as SharePoint’s MicrosoftSharePointTeamServices and X-SharePointHealthScore header. And no, this is not SharePoint 2010 or 2013 running on Windows Server 2012, the Server header comes from the ARR IIS8 server instead of the SharePoint server.

This should hopefully help you investigate alternative options from Microsoft for reverse proxy server.

Advanced installation options for the ARR include leveraging an IIS Shared Configuration which allows you to join multiple IIS ARR servers with identical configurations. You must have a CIFS/SMB share available to store the configuration. In addition, you can examine using Windows Network Load Balancing as a free option to balance requests between the IIS ARR servers (but it is highly recommended to investigate hardware load balancer alternatives).

The IIS ARR itself will do far more than I’ve outlined here. For other features, take a look at the IIS.Net Application Request Routing site!

Trevor Seward is a Microsoft Office Apps and Services MVP who specializes in SharePoint Server administration, hybrid scenarios, and SharePoint Online. He has been working with SharePoint for 16 years from SharePoint 2003 on up, managing environments with terabytes of content for 150,000+ user organizations. Trevor is an author of Deploying SharePoint 2016 and Deploying SharePoint 2019. You can find him on Twitter and in /r/sharepoint.