Using IIS ARR as a Reverse Proxy for Lync Server 2013

With Forefront Threat Management Gateway (TMG) 2010 now discontinued, we sought a suitable reverse proxy solution that works with Lync Server. With the release of Windows Server 2008, it is now possible to add an optional component called IIS Application Request Routing (ARR) 2.5 to the Internet Information Services (IIS) role. This component enables IIS to handle reverse proxy requests, URL rewrites, and load balancing, among other features.

Author: Koen Wagenveld, Brandon Consulting Ltd.

Technical Reviewer: Rick Kingslan

Editor: Susan S. Bradley

Publication date: February 19, 2013

Product version: Lync Server 2010, Lync Server 2013, Windows Server 2008

With Forefront Threat Management Gateway 2010 now discontinued, we sought a suitable reverse proxy solution that works with Lync Server. (The Exchange and SharePoint Product Teams do not support IIS ARR today.) With the release of Windows Server 2008, it is now possible to add an optional component called IIS Application Request Routing (ARR) 2.5 to the Internet Information Services (IIS) role. This component enables IIS to handle reverse proxy requests, URL rewrites, and load balancing, among other tasks. For details and download, check out the Application Request Routing page of the Microsoft IIS website.

NOTE: IIS ARR is supported on Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012. It is also supported On Windows Vista, Windows 7, and Windows 8 with the Web services features installed. Also, IIS ARR does not require IIS 6.0 compatibility mode.

So why is a reverse proxy required? Aside from security considerations that arise if you use network address translation (NAT) directly to your Lync Front End Server in your LAN (which is never recommended), this also requires your firewall to do port translation. Lync Server uses two websites to service its web requests, one for the internal network and one for the external network. The external website listens on port 4443, instead of on the standard port 443, thus requiring a reverse proxy to translate between the two, as shown below in Figure 1.


Figure 1. IIS ARR as a reverse proxy in the perimeter subnet


The following points should be true for your deployment:

  • Lync Server 2013 or 2010 deployed and functional internally.
  • For Lync Server 2013: Office Web Apps Server deployed in your LAN to handle PowerPoint presentations within Lync conferences.
  • Lync Server Edge server deployed and functional.
  • Simple URLs defined and working internally. For this article I am using separate domain names for each simple URL. Check out these URL recommendations.
  • Windows Server 2008 or later computer deployed in your perimeter network. I am using Windows Server 2008 R2 SP1.

To start, ensure that the computer you’re using for ARR has its default gateway in your perimeter network and is able to browse the Internet. Also ensure that the machine is not joined to your Active Directory domain. In my example (very similar to the Lync Server Edge server), I use one NIC in the perimeter network and one in the LAN. The ARR computer must be able to receive requests from the Internet and route them to your Lync Server Front End server. For name resolution, you can use an internal DNS server or use the HOSTS file to specify the simple URLs that you’re establishing. For my deployment, I used the following simple URLs:

  • (meeting invite)
  • (dial-in settings)
  • (external web services)
  • (Lync mobility)

Ensure that each of these names resolve on the ARR server to your Lync Server Front End server. It’s best to use an additional name for the Office Web Apps external URL, but in this example, I configured Office Web Apps to use the same external URL as our Lync external Web Services. Thus, we don’t have to add an additional name to our SAN certificate.

Important: It is highly recommended that you use a distinct rule for your Office Web Apps server. By default, unlike Lync Server web services, the Office Web Apps server listens on HTTPS/TCP/443 and has a distinct fully qualified domain name and DNS name. Additionally, the suggestions here for the Office Web Apps server rule uses ^en-us/ as part of the rule set. If you support languages other than United States English, this rule may fail.

Installation Steps

To install Internet Information Server and the Application Request Routing module, complete the following:

  1. Install the .NET 3.5.1 feature.
  2. Install IIS including .NET and Tracing.
  3. Install your UC SAN cert, root certificates, and add your internal CA root certificate.
  4. Add an HTTPS binding on the Default website in IIS using the UC SAN certificate.


Figure 2. Edit Bindings and assign your certificate to enable SSL/TLS

  1. Download Microsoft Application Request Routing Version 2.5 for
    IIS 7
  2. Follow these ARR Version 2 installation instructions
  3. Create a server farm (this can be a friendly name), as shown below in Figure 2.


Figure 3. Specify a Web farm name

  1. Specify the server address (use the simple URL DNS name and change the ports, as shown below in Figure 4.


Figure 4. Configure properties for the Web farm members

  1. In the server farm settings, as shown below in Figure 5, do the following:


Figure 5. Configure Caching, Proxy, and Routing Rules

  1. Under Caching, disable the disk cache.
  2. Specifically for Lync External web services, under Proxy, change the time-out to 200 seconds. Setting the time-out value to a value greater than 180 prevents the Lync Web App from experiencing disconnecting and reconnecting unexpectedly. The actual value for this setting will need to be tested for each deployment. Factors in your environment will affect what the correct setting will actually be.
  3. Under Routing Rules, disable the SSL offloading option.
  4. Repeat these steps for each simple URL you have. The goal here is to retain the simple URLs as they pass though ARR, so the Lync Front End URL rewriting rules recognize each simple URL as it comes in from ARR.
  5. Edit the URL rewriting rules in the IIS root, as shown below in Figure 6.

Figure 6. Location of the URL Rewrite rules component in IIS

By default for each server farm, an HTTP rule is created. These can be disabled or removed, because we’re interested only in HTTPS.

  1. 15. For our Lync External web services example, add the {HTTP_HOST} condition to match lyncweb.*, as shown below in Figure 7.


Figure 7. Edit your rules in URL Rewrite

  1. 16. Under Action, ensure that the correct server farm is specified, as shown below in Figure 8. Repeat this step for each simple URL.


Figure 8. Ensure that the correct server farm is specified

  1. To add Office Web Apps support using your Lync External web services URL, create a server farm for Office Web Apps (called wac01 in Figure 10). Move the URL rewrite rule above your External web services rule. Then add the following pattern, as shown below in Figure 9:



Figure 9. URL rewrite rule expression and condition for Office Web Apps server

Configured this way, all virtual directories matching this pattern will be directed to our Office Web Apps server and everything else will be directed to the Lync Front End.

The result should approximate what is shown below in Figure 10.

Figure 10. Example URL Rewrite rule set for Lync Server and Office Web Apps server

Changes required to support Exchange

  1. To add Exchange web services, add a server farm as above and specify your Exchange server as the target. My rules are shown below in Figure 11, including a HTTP to HTTPS redirect.

Figure 11. Example rewrite rules for Exchange web services.

Additionally, make the following changes to fix issues with RPC over HTTP:

  1. Under the IIS root, open Request Filtering. Click Edit Feature settings on the right and change the Maximum allowed content length to 2147483648, as shown below in Figure 12.


Figure 12. Redefine the maximum allowed content length

  1. Under the Exchange Server farm Proxy settings, change the time-out and Response buffer threshold, as shown below in Figure 13.


Figure 13. Adjust Time-out and Response buffer threshold values


To troubleshoot, the best place to start is with the IIS log on the ARR server. Browse to this default folder: %SystemDrive%\inetpub\Logs\W3SVC1.

To see what ARR is actually doing under the hood and to configure Failed Request Tracing, review the article titled, Using Failed Request Tracing Rules to Troubleshoot Application Request Routing (ARR). This process creates XML trace files in this folder by default: %SystemDrive%\inetpub\Logs\FailedReqLogFiles\W3SVC1.


You should now have a single server in your perimeter network, using a single IP address and a single certificate to reverse proxy all Lync workloads, with the option to add Exchange and SharePoint workloads. For highly available deployments, I anticipate that hardware/appliance load balancers will fill the gap and provide similar features in the near future (if not already available).

Additional Information

Lync Server Resources

We Want to Hear from You

Keywords: IIS, reverse proxy, IIS ARR, application request routing, TMG, threat management gateway

Comments (72)
  1. Andrew says:

    What is UC SAN certificate and where do I get it from?? Do I need it if the topology is on internal network (no internet) also I dont have Office web server.

  2. Anonymous says:

    Sometime ago we got into a situation where a customer deployed ARR as a Reverse Proxy for Lync Server

Comments are closed.

Skip to main content