Using IIS Application Request Routing (ARR) as a TMG Replacement

February 12, 2013

So this won’t be shocking news but Microsoft has stopped selling Forefront Threat Management Gateway (TMG) and they really didn’t give us any good alternatives.  Officially, they tell you to use the Unified Access Gateway but anyone who uses it knows that 1) it’s a massive pain to setup 2) it’s really expensive 3) it breaks autodiscover and mobility.

So this leaves us to use third party hardware load balancers but I’m not much of a fan of doing firewall rules directly to the HLB.  The nice thing about the reverse proxy is that it served as a separation between the internet and production.  So I have found some articles on the web about IIS ARR with Lync but they all seem to be 1) not written for Lync 2013 2) don’t work with mobility 3) are too vague 4) assume that you are going to bind one service to one IP – which works find but sometimes people want to not take up a ton of IP’s on the internet to deploy one service.

So this will attempt to guide you through the configuration of ARR to work with Lync Server 2013.

UPDATE: I’ve been asked does this work with Lync Server 2010 and the answer is yes.  I haven’t spent as much time testing every option yet but it does appear to work fine.


First you need to install IIS on your Windows 2008 R2 or Windows 2012 Server.  I like to click the Application Server which will install pretty much everything you need in terms of .NET Framework.

The second item you need is ARR. This can be installed by downloading version 2.5 + hotfixes from Microsoft’s website or you can use the Web Installer (  This is how I typically install the product:


Search for ARR and select Application Request Routing 2.5 (which will select the hotfixes) and install search for rewrite and install URL Rewrite 2.0.

NOTE: I see that 3.0 Beta is now available.  Feel free to try it out – it worked for me but I’m going to production with ARR so I want to use non-beta software for now.

IIS Configuration

This isn’t meant to be an all encompassing lesson on how to use IIS so I’m going to assume you have some basics under your belt.  You need to make sure that your public certificate is installed on the IIS server.  Go to bindings of your default website and bind your SSL certificate to this server.  This certificate must have a private key associated with it.  Also, make sure that your internal root certificate authority is installed on this server as well.  My test server is not domain joined so I have to install it manually.

Ultimately, your website is going to contain the IP address you plan to listen on.  So this is very similar to the concept of a listener from the TMG world.  You have the same limitation in terms of certificates and IP’s in IIS as you do in TMG.  So if you have two certificates you plan to use on the reverse proxy you will need to bind two IP’s to your IIS server and create two websites.  This guide is going to assume a single website/single IP address for Lync, Exchange and Office Web Apps (OWAS) as I have a single certificate with all of those names on it.

ARR Configuration

NOTE: I had a section on how to enable the proxy within ARR here at first because I was under the impression it was needed for this to work.  Got word from a Lync friend that it wasn’t needed and indeed it was an extra step in the configuration that didn’t harm anything just wasn’t required for the configuration.  Thank Corrado!

Server Farms

Server farms are the targets of where we might send traffic to.  There isn’t a direct correlation to something in TMG but the big thing to know is that ARR does more than just a reverse proxy.  It is a load balancer and more.  So we need to create a farm for Lync.

In IIS Manager, Click on Server Farms and right-click and choose Create Server Farm.


Enter a name

Click Next

Enter the server IP address.  Click on advanced settings and change httpPort to 8080 and httpsPort to 4443.  If you are going to use the load balancing feature, add all of your front-end servers in the pool.  If you have a HLB, than this server IP should be going to your HLB.


You will get this message.  Click the Yes button to create a default rules.

Now you should see your new server farm.  Click on the Lync farm you just created and find Routing Rules.  Double click on it and disable SSL Offloading. There is no reason to offload on the ARR box as far as I can figure out.  If someone has a good reason to leave it on let me know.

Make sure to click Apply in the Action pane on the right when you are making changes in IIS.

Your farm is now configured and setup.  If you want you can create two more farms, one for Exchange and one for OWAS.

URL Rewrite Rules

Now it’s time to get to the meat and potatoes of the configuration.  We are now going to setup URL Rewrite (or really reroute rules).  This is very similar to the firewall rules that you had in TMG.  They don’t have all of the same features but covers what we need.

In IIS Manager, click on the Server


NOTE: This is URL Rewrite on the server.  Don’t go to the website.  There is a URL rewrite option there as well.

When you go into URL Rewrite you will find two default rules created for you.  The first is the SSL rule and the second is the HTTP rule.  Since I don’t want to use the HTTP rules I am simply disabling them.  You could delete them if you want I suppose as well.


Double click the ARR_Lync_Loadbalance_SSL rule and let’s understand what you see here:


In the Match URL is basically what we are going to make after the / in the URL.  So if our URL was the pattern would be /website for example.  You will see under Using you will have the option to use Regular Expressions.

The Conditions is a set of inputs that are required to match this rule.  Here we will we have HTTPS which basically means we must match SSL requests only.


This is a continuation of the above.  The Action section tells us what we should do if we match.  So here we will route to the Lync Server Farm.  This part is pretty straight forward and will be basically the same for all rules.  So let’s create our first Lync Rule.

Meeting/Dialin/External Web Services Rule

Here you have some options based on how you do your simple URLs.  If you do “Option A” where you URL would look like: and then you would need to use the below rule.

Change Using to: Regular Expression

Change Pattern to: (.*)

If you use Option B where your simple URLs might look like this: and your rule would look like this.


NOTE: You will need to change dialin and id to whatever you use if using Option B for simple URL’s

NOTE: This is the list of all potential directories as of RTM of Lync 2013.  CU1 will most likely add some items so this may need to be edited.

Add to Conditions: {HTTP_HOST} on the pattern of (||

NOTE: You should NOT add to this rule.  The reason we don’t want to add this is because our regular expression doesn’t include the root of the website and won’t match any of these rules.  If you wanted to, you could change your pattern to (.*) and add to the list. I don’t have a good reason to do it either way.  Whatever makes the most sense to you but I like to separate them out.

Lync Discover Rule

Now we create a rule for Lync Discover services.  Here is what I have created.  This rule is created as brand new and not one of the existing rules.


Here I am defining my pattern match as any request (.*) anything from URL.  Here I am not requiring HTTPS on this rule Lync Discover will use either HTTP or HTTPS.

OWAS Rule Setup

If you created your web server farm for OWAS you should have your default rules again.  So if I look at that rule:


This rule again is pretty straight forward.  We are matching anything intended to go to  The big difference is under Action, our Server Farm is now OWAS and not Lync.  You can do the same thing with Exchange or other services as well.  Here is my completed configuration:


Services Tested

I have tested the following services to make sure they work through ARR.

  • Meeting Join URL
  • Dial-In Website
  • Web Scheduler
  • Mobility

The only thing I haven’t tested thus far is the Lync MX (Metro/Win 8) client.  I’ll try to get remote of my lab and test that later this week.  My history thus far with the Lync MX client is a complete crap shoot – where mobility works but MX doesn’t.


So what are some common problems I’ve found while setting up ARR.

#1 – Make sure you can reach your websites from your ARR server.  If the ARR server can’t reach these websites it’s not going to work from the outside.

#2 – Certificates.  Ensure that your internal server has your internal CA root certificate.  If this box isn’t a domain joined server, it won’t be there.  If you did #1 you shouldn’t have this issue because you would have fixed it when the certificate error appeared.

#3 – Make sure your internal certificates have the right names.  For example on OWAS.  If your internal FQDN is and your external FQDN is, your internal certificate should have BOTH names on it.  Your internal users will look up based on the internal name and when your external people go to that server, they will proxy through ARR with the external name.  It doesn’t have to be a public certificate but it needs to have the name.

Hopefully that covers the most issues you might run into and this gets you on the right page for using ARR and Lync 2013.


I found that you will want to adjust the timeout on the IIS or you will see some timeouts with the new Lync 2013 Mobile Client.  On the Proxy Settings | Time-out – change from 30 seconds to 180 second.




Written by Richard Richard is an Office Apps & Services MVP (Teams / Skype) who lives in Minneapolis, MN. Microsoft Certified Solutions Master (MCSM) and MCSM Instructor - when those were a thing long ago. When not writing code, breaking teams - debate coach and avid golfer.
Follow on Twitter

Built using Gatsby and Material-UI

Copyright © TheArgyleMVP 2022.