IIS ARR configuration as a Reverse Proxy for Lync

Straight to it – If you’re expanding your Lync environment to cater for external, remote, or federated users, then you’ll need a reverse proxy solution such as IIS ARR (as well as your Lync Edge role) to provide said users with a feature rich Lync experience. The Reverse Proxy is not actually recognised as a Lync role, but is instead a supporting component. As such you will not find any reference to the Reverse Proxy in places such as the Lync Topology Builder. By definition a Reverse Proxy retrieves resources from one or more servers on behalf of a client request. From a Lync perspective, this allows external clients to access Lync web services hosted on our Front End servers and provides the following functionality;

• Allows external users to download meeting content for your meetings.
• Allows external users to expand distribution groups.
• Allows remote users to download files from the Address Book service.
• Allows access via the Lync Web App client.
• Provides access to the Dial-in Conferencing Settings webpage.
• Provides access to the Location Information service.
• Provides external devices access to the Device Update web service.
• Enables Lync mobile applications to discover and use the mobility URLs
• Allows Lync 2013 clients to leverage Lync Discover URLs

There’s no shortage of Reverse Proxy solutions, and many of today’s firewalls and load balancers provide this functionality as part of their feature set. Although not as granular as a dedicated security appliance in terms of inspection, this role can also be filled using Internet Information Services with the Application Request Routing extension (IIS ARR), here’s how…

Prerequisite Host Configuration

The Windows Server that will host your IIS ARR service will sit in your DMZ / perimeter network. Best practice from a security perspective dictates that a true DMZ be defined by both internal and external firewalls as below with your Reverse Proxy sat in between, completely independent of your internal network.


Often however (much more often), you will come across Lync topologies where there is but a single perimeter firewall in use. In this instance the Reverse Proxy will have a foot in the internal network as below (although it is also possible to have a 3-legged firewall configuration in such a scenario).


Regardless, the important thing to note is that in both instances (and those are just two examples of common topologies) the Reverse Proxy has two network adapters, each on a different subnet. Our Lync Front End servers are listening on 4443 for external web service requests which initially come in on 443 from external users, and are translated by the Reverse Proxy (IIS ARR) to 4443 before being passed to the Front End pool.

Typically your Reverse Proxy solution is one of the penultimate Lync components that you will deploy and configure, so you should already have a fully functional internal Lync environment with working Edge services at this stage. The following prerequisite actions should be performed on a host server prior to installation and configuration of IIS ARR;

• Complete installation of Windows Server 2008 or later to host IIS ARR
• Allocate internal and external network adaptor IP addresses
• Install all available Windows Server updates
• Name the server inline with the domain naming convention
• Rename the workgroup of the server if desired (server should not be on the domain)
• Add your domain name as a primary DNS suffix to the server name
• Import the root certificate of the CA that has issued your internal Lync certs
• Add an A record host entry for the server to your internal DNS records

The external network adaptor on the server should have a default gateway, but no DNS servers associated to it. The internal network adaptor should not have a default gateway listed, but may have DNS servers associated to it if your internal DNS servers are on the same subnet as the servers internal adaptor (like the second diagram in this article), or you have a DNS server in your DMZ. If you’re server will be in a true DMZ (as per the first diagram), then you will need to create persistent routes to your Lync Front End pool and Office Web App servers subnets accordingly, and you will also need to create host file entries on the server to ensure that all your simple URLs (meet, dialin, lyncdiscover, and lyncwebext) can be resolved to the Front End pool.

IIS ARR Installation and Configuration

OK, nice clean Windows server sat in our DMZ – lets do what we’re here for and install our IIS Reverse Proxy. I’ll be performing the installation on a Windows Server 2012 R2 box, so you may need to compensate slightly if you’re hosting things on a different OS.

Step 1 – IIS Installation
Open up server manager and install Web Server (IIS) as a role. Nothing out the ordinary here, leave all the defaults in place and next next yes yes install your way through to the end.


Step 2 – Application Request Routing Installation
Download the Application Request Routing extension from here. Once the web platform installer is available you’ll be presented with the install option – click Install.


At this point you will be advised of the components that are to be installed (ARR 3.0 at time of writing), as well as any additional hot-fixes that might be relevant to ARR. Click Accept to continue with the installation.


Once complete you can select Finish and Exit, as there is no requirement to add any other products via the web installer.


Step 3 – Certificate Installation
As mentioned earlier in the ‘Prerequisite Host Configuration’ section of this article, ensure that the root certificate for the CA infrastructure that issued your internal Lync certificates (Front End servers etc) is imported into the local Trusted Root Certificate Authorities store.

Next we need to import our external / public certificate. From IIS Manager access Server Certificates management as below. (Certificate provisioning is outside the scope of this article, for details on Reverse Proxy certificate requirements please see here)IIS ARR

From here use the import option in the right hand column to import your external / public certificate. Once complete the certificate details should be visible in the Server Certificate window. (I have omitted all my cert details bar the ‘Name’ column in the screenshot).


Step 4 – Certificate Binding
Select the Default Web Site node from the left hand column in IIS Manager, then select Bindings… from the right hand column under the Actions menu. The site bindings windows will appear for the default web site that will have a single entry for HTTP. Click Add, change the type to HTTPS, and select your newly imported SSL certificate using the drop down box. Click OK once complete.

Step 5 – Server Farm Creation
We need to create a server farm for every name that we want to publish (meet, dialin, lyncwebext, lyncdiscover, and wac in this case). To create our first farm, right click on the Server Farms node in the left pane of IIS Manager and select Create Server Farm…

In the Server Farm Name field enter the FQDN of the first service to publish – I’ll be publishing the dialin service first. Note that this FQDN is resolvable from the public domain and should also exist listed the public certificate we previously imported.

On the next page, before populating the Server Address field, click the Advanced Settings option and expand the tree. Change the HTTP and HTTPS port values from 80 and 443 to 8080 and 4443 respectively. Then populate the Server Address field with the FQDN of your Front End Server (or HLB VIP address if load balancing these services) and click Add, then Finish. Click ”Yes’ the URL re-write message that appears.

Repeat the above process to create server farms for the remaining services. Remember that your Office Web App (WAC) service is going to have a different server FQDN, and will also keep the default 80 and 443 port values. As it is not part of the Lync Front End web services we do not need to change these to 8080 and 4443. Once complete your Server Farm node should look similar to the below.

Step 6 – Server Farm Configuration
We now need to make some configuration changes to the default server farm settings. Select the first farm in your list and choose ‘Caching’. Uncheck the Enable Disk Cache’ option. Repeat this process for each of your server farms.

Select the first farm in your list once again, and choose ‘Proxy’. Change the Time-out value from 30 to 900. The official Microsoft IIS ARR configuration guidance is to set this value to 200. However you will notice that mobile IOS (iphone) users will often get persistent prompts asking them to restart their Lync client. The prompt is a result of this value being set too low. It varies by environment but the threshold typically ends up being around 600-900 seconds for most environments. Repeat the process for all farms.

Select the first farm in your list once again, and choose ‘Routing Rules’. Uncheck Enable SSL Offloading. Repeat the process for all farms.


Step 7 – URL Rewrite Configuration
In the left pane of IIS Manager, select the IIS home node (root) and the choose URL Rewrite from the main pane.

All your URL rewrite rules will be listed for both HTTP and HTTPS similar to below

We will not be using HTTP for security reasons, so can delete all the rewrite rules associated with HTTP by selecting them and choosing Remove from the right hand pane in IIS Manager. Use the ‘Action URL’ column to identify these rules as they are prefixed with HTTP as opposed to HTTPS. This should half the amount of rules you now have.

Finally we need to add some conditions to our remaining HTTPS rewrite rules. Select the first rule in your list, and then choose ‘Add…’ from the Conditions menu in the right pane of IIS Manager.

Change the Condition Input to {HTTP_HOST} and type the pattern as the first part of the FQDN for the rule you are editing followed by a star. For example, I am adding a condition to my dialin rule, so my pattern becomes dialin.* as per the screenshot. Repeat the process for each URL Rewrite rule.


And…..We’re Done
That’s all there is to configuring IIS ARR as your Reverse Proxy. You can test your configuration with ease simply by browsing to your meet or dialin URL’s. Naturally there are other components at play that a working Reverse Proxy configuration will depend on such as certificates, external DNS, and firewall configuration – but all those things being well you should hit your meet or dialin web pages without issue. At time of writing this article IIS ARR continues to be a very popular Reverse Proxy solution for Lync web services, after all it’s essentially free if you already have your server licensing covered by an agreement of sorts. Bare in mind my earliest comments though;  that you may already have a proficient networking device sat in your perimeter network that could be capable of performing this role already.



Posted in Lync 2013 and tagged , . Bookmark the permalink. RSS feed for this post. Leave a trackback.

One Response to IIS ARR configuration as a Reverse Proxy for Lync

  1. Hi there, You have done a great job. I will certainly digg it and personally recommend to my friends.
    I’m sure they will be benefited from this web site.

Leave a Reply

Your email address will not be published.

Copyright © 2014 · All Rights Reserved