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:

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!

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

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.

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

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.

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.

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.

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:

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:

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

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:

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!


  1. Great post! First time I have heard of a valid MS alternative to using the Forefront TMG.

    I am missing the step where you’re accessing the SharePoint from an external address (e.g. and you are being served the internal server (e.g. sharepointwebapp). Also I would like to know how this would work with an NLB (software based). Would I just have an additional IIS route the requests to my e.g. 3-server SharePoint farm and the ARR01 server route to that NLB? Last question: Who is serving the login page? TMG created this nicely looking login page where users could authenticate against the Active Directory – would SharePoint serve that then or would I have to create a custom login page?

    • You will need to make sure that SharePoint responds to the external address ( as that is what IIS ARR will route (unless you delve in and create more complex URL Rewrite rules). I originally wrote this article with the intent of showing Windows Network Load Balancing, but because of the network layout I have, it didn’t make much sense. WNLB does not require 2 NICs, but it can be configured that way. At any rate, what you would do is create your first ARR server, then enable IIS Shared Configuration, storing the configuration on a 3rd CIFS server. Next, you’d build up a second ARR server, installing the same software and SSL certificate, as well as configuring the registry and services, then point it at the shared configuration on the CIFS server. It will bring in the configuration of the Default Web Site, DefaultAppPool, and Server Farm. You would then install Windows NLB (Add-WindowsFeature NLB) on each node. From a remote machine with the RSAT-NLB feature installed, you would create an NLB array, connecting to the first node. Use IGMP Multicast, if possible. Specify only the ports you want to leverage (tcp/80 and tcp/443) for better performance, using Single Affinity. Join your second ARR server to the array. You will then point external DNS at the NLB VIP, and you can independently bring up and down ARR nodes! Neither the IIS Shared Configuration nor the configuration of Windows NLB from a remote machine require domain membership, you’ll be prompted for a machine username and password as required.

      IIS ARR does not have a “portal” like TMG or UAG. ARR will always pass the authentication directly back to the SharePoint server.

  2. Awesome post! I will have to try this one out. Thanks Trevor!

  3. Is there a way to doing this same thing without NLB, but with 2 unique second level domain SSL certificates?

  4. Trevor, I’ve created a SharePoint farm without using any SSL. I now want to give secure access to SharePoint to domain users who are physically outside my network. It seems I can use ARR to do this, but do you have any information that will guide me in turning on the SSL functionality within SharePoint once SharePoint is up and running?

    • You can certainly use AAR, but it isn’t necessary to use any reverse proxy. Basic steps for configuring a pre-existing Web Application for SSL are:

      1) Install the SSL certificate from your SSL vendor
      2) [Sometimes optional] Import the public root authority certificate in your SSL certificate chain in Central Administration -> Security -> Manage Trust
      3) Create an SSL Alternate Access Mapping in Central Administration, e.g., for the Web Application. This must match your SSL certificate (or match the domain if the certificate is a wildcard)
      4) Add the SSL binding to the IIS Site for your Web Application in IIS Manager

      Then, open TCP/443 on your edge device to the SharePoint server, or a reverse proxy configured to route traffic to your SharePoint server.

  5. nice article , mmm , what if i need to the extranet user to be redirected to a specific subsite :) ?

  6. Thank you!! I was really struggling getting this SP instance of mine exposed to the outside and your note about making sure the FQDN resolved correctly on the proxy machine was KEY and saved me hours of debugging toil. I was nearly ready to upgrade the proxy machine to 2012 R2 to see if the new Gateway role would work any better. Thank you again!

  7. Do you have any idea if using this method I could have Skydrive Pro to sync docs with my on premises SharePoint while I’m outta of the office (Lets assume that my internal domain name matches the public DNS domain)?

  8. Hi Trevor,

    If we are configuring SSL Offloading using ARR, whether “Open with explorer” functionality will work in SharePoint?

    Noticed, it is failing for other reverse proxy devices.


  9. @Trevor, Your External Disk Cache and ARR installation commands are in the reverse order — it needs to be ARR, THEN the External Disk Cache. Please correct your instructions – I was having a terrible time trying to get ARR to show up in IIS until I followed the order from . You also need to include the command “Import-Module bitstransfer” before the Start-BitsTransfer commands. Great commands, otherwise, though I didn’t try the SSL pieces.

  10. @Trevor, Also, you forgot to add stopping WAS (which stops W3SVC) and restarting it:

    Start-Service WAS
    Set-Service WAS -Startup Automatic
    Start-Service WMSVC
    Set-Service WMSVC -Startup Automatic
    Start-Service W3SVC
    Set-Service W3SVC -Startup Automatic
    Start-Service WebFarmService
    Set-Service WebFarmService -Startup Automatic

    I also found I had to add a registry entry to get the WebFarmService to start, which would go prior to those commands:

    New-ItemProperty ‘HKLM:\SYSTEM\CurrentControlSet\Control’ -Name ServicesPipeTimeOut -Value 60000 -PropertyType Dword


Leave a Reply