Using ARR for Reverse Proxy with Lync 2013

In an earlier blog post I wrote about publishing Lync services using TMG 2010. One of the Microsoft alternatives for reverse proxy is the Application Request Routing module or ARR, a module that’s running on top of Internet Information Server (IIS).

Lync Configuration

In my lab I have a Lync 2013 Enterprise Edition, in the perimeter network I have a Lync 2013 Edge Server, but instead of a TMG I now have an IIS/ARR server.

The following FQDN’s are ‘published’ via the Lync 2013 Edge Server:

  • (sometimes sip.<YourDomain> is used here)

These services are used by either external Lync clients or for federation purposes (i.e. Lync connectivity with other Lync organizations).

The following FQDN’s are web services internally running on port 4443 and port 8080, so they need port translation to publish them to the internet using port 443 and port 80:



Note. The internal name of the Lync Front-End pool is but the external name is This can be configured using the Topology Builder.

Server Configuration

A reverse proxy is meant to be installed in the perimeter network and as such it cannot be a member of the internal Active Directory domain. The server needs an FQDN as well, so besides a normal server name you have to enter the DNS suffix. In my lab environment this will be


I have been using Windows Server 2012 R2 with 2 NICs of course. Make sure you’ve the the name resolution working correctly otherwise you’ll be presented all kinds of funky error messages.

There’s no need to install prerequisite software, this will be installed during the installation of IIS/ARR. ARR is a module on top of IIS. To install ARR you can use the Web Platform installer on You can also use ARR version 3 which can be downloaded here:

ARR is installed using the web platform installer, so click the link, click Run (or Save if you want to store on disk first) and follow the wizard.


As you can see in the screenshot the IIS prerequisite software is automatically installed.

SSL Certificate

Since the web services are using HTTPS you have to use an SSL certificate on the ARR server. I’ve seen deployments where one certificate was used both on the Lync Edge Server and the Reverse Proxy server, but a dedicated SSL UC certificate is possible as well. Personally I’m using Digicert certificates for this. Make sure you use an SSL certificate with the proper FQDNs (meet.<yourdomain>, dialin.<yourdomain> and lyncweb.<yourdomain>) in the Subject Alternative Names field of the certificate.


When the SSL certificate is imported you have to bind it to the webserver in IIS Manager. Open IIS Manager, select the Default Web Site and click Bindings in the Action Pane. In the Site Bindings window click Add, select https in the Type dropdown box and select the SSL certificate we just imported in the SSL Certificate dropdown box.


Click OK and click Close to finish the wizard.

The server is now fully installed and ready to configure ARR.

Configure ARR Server Farm

To make sure the Worker process for the Default Web Site always runs you can disable the Idle Time-Out feature for the main website application pools. To do this, open IIS Manager, expand the server ARR01, click on Application Pools and select the DefaultAppPool in the results pane. In the Actions Pane click Advanced Settings. In the Advanced Settings window change the Idle Time-Out feature to 0 (minutes) to disable this feature.


Click OK to save the new setting and close the Advance Settings window.

Configure Simple URLs in ARR

To create the Server Farms for each of the simple URL follow these steps. We’ll start with the simple URL, but you have to repeat these for the and the Simple URL.

In IIS Manager right click on Server Farms and select Create Server Farm. In the Create Server Farm window enter the name of the new Server Farm (i.e. and click Next. Enter the Server address of the internal Simple URL (I’m using split DNS so this is again, make sure it resolved to the internal IP address and NOT the external IP address of the ARR server!!) and click on Advanced settings…. In the applicationRequestRouting field change the httpPort to 8080 and the httpsPort to 4443.


Click Add to add the server to the server farm and click Finish to close the Create Server Farm wizard. A Rewrite Rule pop-up window is shown, asking to rewrite all incoming requests to this server farm automatically. Click Yes to confirm.

To configure the new Server Farm select it in IIS Manager under Server Farms. In the details pane double click on Caching. Uncheck the Enable disk cache option and click Apply.


Select the server farm again and double click on Proxy. Change the Time-out value from 30 seconds to 200 seconds and click Apply.

Select the server farm again and double click on Routing Rules. Uncheck the Enable SSL offloading option to disable SSL offloading and click Apply.

Repeat these steps for the Simple URL.

Repeat these steps for the Simple URL, but in the Server Address field use the internal FQDN of the Lync Front-End server (for example LyncFE01.labs.local). If you have multiple Lync Front-End servers just add them to the lyncweb server farm. This is shown in the following figure.


URL Rewrite Rules

When you’ve configured the Server Farms the last step you have to do is to configure the URL Rewrite Rules. In IIS Manager Select the server root node (like ARR01 (ARR01\Administrator) in this example) and in the details pane double click on URL Rewrite. A list of 6 URL Rewrite rules should appear. Every server farm that was created in the previous step has two rules, one HTTP and one HTTPS. Since we will only be using HTTPS you can safely delete all the HTTP rules.

This will result in something like this:


In the URL Rewrite list, select the ARR_meet_exchangelabs.nl_loadbalance_SSL rule and click Edit (under inbound rules) in the Actions Pane. In the inbound rule editor, click Add in the Conditions section and enter the following:

Condition input: {HTTP_HOST}

Matches the pattern

Pattern: meet.*

Click OK to add this condition to the list.


In the details pane, scroll down a bit to the Actions section, make sure the Action properties are set to:

Action type: Route to Server Farm

Scheme: https://

Server farm:

Path: /{R:0}

Click Apply to save these settings. Repeat these steps for the dialin rule and the lyncweb rule.

Testing the reverse proxy

To test the reverse proxy make sure the IP address for the three services (meet, dialin and lyncweb) are set in DNS and can be fully resolved (and there’s not firewall blocking stuff of course).

Using your browser navigate to:

You’ll see the following in your browser:


The dialin page will be like this:


The Lync Web Scheduler will show a login form and after entering user credentials you’ll see the scheduler itself:



IIS/ARR is another Microsoft solution for reverse proxying your Lync environment. It’s easy to use and fully supported (of course). An interesting solution if you don’t want to use a load balancer for this.

15 thoughts on “Using ARR for Reverse Proxy with Lync 2013”

  1. Hi! Congrats on the article, very good!

    Please can you tell me:

    Can I use the same reverse proxy for Lync 2013 and Exchange 2013? They will use the same certificate (wildcard)

    How can we build a high available reverse proxy? This “one reverse proxy scenario” has no high availability.

    Thanks a lot!


    1. Same reverse proxy with same wildcard certificate will be challenging, I assume you also want to use a single IP address?
      If you want to add HA to this solution you have to add a load balancing. I have had it working with a hardware load balancer, but I assume NLB should be possible as well.


  2. Thanks Jaap, more Lync issues
    The online remote connectivity analyzer completes successfully, I can view the web ticket.

    The only test that fails is the Lync connectivity analyzer with the following errors.

    An error occurred while sending the request.
    The remote name could not be resolved: ‘ad-lc-01.domain.local’

    ‘ad-lc-01.domain.local’= Lync Frontend

    Couldn’t connect to URL (HTTP status code NotAcceptable)

    All my mobile clients cannot function.



    1. DNS resolves this FQDN successfully and it listens on port 80 so you’re fine here. I have no idea why it wants to resolve the internal servername, this should be something in the Lync Topology, so maybe you can have a look here. The ‘HTTP status code NotAcceptable’ however looks like an issue with an invalid translation in IIS/ARR, so you have to check this as well.

      Kind Regards


  3. what if the topology is on 2 internal networks (192.168.x.x / 192.168.10.x ) where do I get UC cert from? I guess it doesnt have to be public cert auth. Can I just generate it on my internal cert auth?


    1. No idea, never tried. I can imagine that you need to add an additional name on the certificate, but I’m not sure if the Office Web Apps server is supported with a UC certificate. But a single name SSL certificate is only a matter of a few dollars, so….


Leave a Reply to jaapwesselius Cancel reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s