Installing and configuring IIS ARR Reverse Proxy on Windows Server 2012 for Lync Server 2013 \ Skype for Business External access

Standard

As Forefront TMG 2010 is becoming end of life, Microsoft’s official and at the moment only supported Reverse Proxy solution for Lync Server 2013 is IIS ARR.
For Skype for Business Server the only supported solution is Server 2012 WAP, but IIS ARR 3.0 will also work for you.

Doing this is rather simple, and this post will demonstrate the steps to publish Lync 2013 External Web Services using IIS ARR on Windows Server 2012.

First things first, an installation and two downloads:

– OR –

  • Install IIS on Windows Server 2012 with all defaults, nothing too smart.
  • Download Hotfix for Microsoft Application Request Routing Version 2.5 for IIS7 (KB 2732764) (x64), we’ll use that later.
  • Use Microsoft Web Platform Installer to install IIS ARR 2.5.

Whichever platform you choose (ARR 2.5 or ARR 3.0), it’s an identical installation and configuration process:

You’ll get the first installation screen, telling you it will install 2 features:

first installation screen

Hitting “Install” will show you the features you’re about to install. That’s 4 components all together:

Installation list

Click “I Accept” and enjoy the commercial content from Microsoft whilst the installation is taking place:

Installation in progress

When the installation is finished, You’ll see it has installed four components:

Installation OK

If your server can’t access the internet for some reason, you’re up for a real treat:

Checking Windows 2012’s Programs and features will show you these exact 4 items. This is all you need for IIS ARR to work:

Installed components

Open IIS Manager, and you’ll see you have two new features:

  • “Server Farms” under the server node.
  • “Web Platform Installer” in the management node.

New IIS features

Configuring the website:

Import your Lync 2013 external certificate to the server:

Certificate list

Navigate to your default website in IIS Manager and click “Bindings”:

Website Bindings

You’ll see it has only the HTTP binding. Click “Add” to edit the HTTPS binding:

Add Bindings

In the next window, choose “HTTPS” from the drop down menu, then choose your Lync external certificate, and press “OK”:

Choose Certificate

This completes the configuration of the web site.

Create Server Farms:

Guidelines:

  • We need to create a server farm for each name we’re publishing.
  • The Internal root CA (The one that’s used for signing the internal Lync certificates) must be placed in the “Trusted Root Certification Authorities” container in your IIS ARR machine.
  • The Internal names of your Lync servers and WAC servers must be resolvable from this server, so don’t forget to add them to your hosts file.

To build the first Server Farm, right click “Server Farms” and choose “Create Server Farm”:

Create server farm

In “Server Farm Name” enter the external FQDN of the service you want to publish.

This can be “Meet.MyDomain.com”, “DialIn.MyDomain.com”. etc. After you enter the name of the server farm, click “Next”:

Meet Farm

On the “Add Server” window, type the name of the server you want to publish and then click “Advanced settings”:

Add Server and advanced settings

Remember to click “Advanced settings” BEFORE you click “Add”. You need to add the server to the farm only after you set the advanced settings for the server.

“Advanced settings” is where we set the port bridging rules from 443 to 4443, just like we used to do with TMG 2010.

Set the HTTP port to 8080 and the HTTPS port to 4443, then click “Add”:

*** For the Office Web Apps farm leave the ports 443 and 80, as these are redirected directly to the server’s website.

Advanced Settings

Now you can see the server in the server farm:

Server ok

Once you click “Finish”, you’ll get a prompt asking if you would like to create a URL rewrite rule:

Rewrite prompt

Choose “Yes”. This will come in very handy in just a few more moments.

Do the same steps for every external address you want to publish.

Eventually, you’ll end up with enough farms to publish all your external addresses:

All Farms

Now, a few adjustments to make this work right with Lync. For each server farm, do the following steps:

Step 1:

Click each server farm and choose “Caching”:

Meet Caching

In “Caching”, uncheck the “Enable disk cache” box:

Disable Caching

Step 2:

Click each server farm and choose “Proxy”:

Meet Proxy

In “Proxy”, change the Time-out to 200:

Time-out

Step 3:

Click each server farm and choose “Routing Rules”:

Meet Routing

In “Routing Rules”, uncheck the “Enable SSL offloading” box:

Disable SSL offloading

After completing these three steps for all server farms, go to the IIS Server Home and click “URL Rewrite”:

URL Rewrite button

The next window will show you all the Server farms with the url rewrite rules that were created earlier (Remember that button?):

URL Rewrite main window

Clicking the ‘+’ sign on the left of each of the server farms will show you the existing URL Rewrite options. One of them is for HTTP, the other for HTTPS:

URL rewrite with HTTP

Since we are not using HTTP, you can remove the HTTP rule (the one that does NOT have the “_SSL” suffix). This will leave you with only the HTTPS rewrite rule.

Click “Add” to add a condition to the HTTPS rule:

URL rewrite only HTTPS

Start typing ‘{HTTP_‘ and choose the {HTTP_HOST} option from the drop-down menu. at the pattern, type the beginning of the FQDN followed by a star, e.g.: “Meet.*”, or “DialIn.*”:

HTTP_HOST add

The result should be like this:

URL Rewrite completed

Repeat these steps for each server farm on your list.

Important note regarding WAC:

One option is to publish it as a server farm as described above.

Another option is described in Koen Wagenveld’s great article on TechNet, to use a regular expression. Please refer to the article if you would like to use this option.

That’s about it! IIS ARR is now publishing your Lync 2013 services.

31 thoughts on “Installing and configuring IIS ARR Reverse Proxy on Windows Server 2012 for Lync Server 2013 \ Skype for Business External access

  1. Chad

    Am I correct to assume that this method will not work with multiple sip domains? Because lyncdiscover.* and meet.* will be conflicting. How could I write the rules differently to accommodate many sip domains?

    • Hi Chad,
      Are they all pointing to the same front end server? If yes, there would be no problem since the requests are forwarded just as they are. So meet.domain1.com and meet.domain2.com pass through the same rule, but each is hitting its respected URL.

      • Chad

        Nice! Yes, same FE server. So that means the names of the server farms are not significant? I would just name the server farms “meet”, “lyncdiscover”, and “lyncweb” or maybe even name them using my primary sip domain…
        I have looked at at a couple of these ARR articles for Lync and this one is very clear and well done. Thanks!

  2. Richard

    Hi,
    Many thanks for this article. Am i correct in saying tha the server names i specify should simply match the server farm name? Such as admin.domain.com, and lyncdiscover.domain,com? Will the server then resolve these using the internal DNS?
    Thanks

    • Hi Richard,
      My recommendation is to match the server’s name to farm name.
      If your IIS is configured right, I’d recommend that it will not resolve internal names using your internal DNS. Use the hosts file for that.

      • Richard

        Thanks. So i would simply add the server farm lyncdiscover.domain.com and set the server as lyncdiscover.domain.com, then add another server farm for lyncext.domain.com and set the server as lyncext.domain.com?

  3. Richard

    My internal DNS is pointing the entries shown above to the IIS ARR server internally. Im guessing this way round it would cause a loop? Should all lyncdiscover.domain.com type of entries be pointing directly to the internal Front End server IP?

    • Hi Dino,
      Thanks for mentioning that.
      KB2732764 addresses a problem in Application Request Routing Version 2.5. When ARR is installed on Windows Server 2012, it fails to proxy Windows authentication.
      You will need to install this on your Windows server to have everything working correctly.

  4. Couple of things. You may want to consider leaving the http rule for Lync Discover to support scenarios where multiple sip domains are used. See http://technet.microsoft.com/en-us/library/hh690030.aspx

    Also, WAC typically listens on port 443. If you follow this process for the WAC server you will get a message saying there could be URL rewrite conflicts with existing farms when you setup the WAC farm. Did you change your WAC Server to listen on 4443?

    Also, WAC typically listens on port 443. If you follow this process for the WAC server you will get a message saying there could be URL rewrite conflicts with existing farms when you setup the WAC farm. Did you change your WAC Server to listen on 4443?

    • Hi Dino, thanks for you input.
      You can leave the http rule if you decide to use HTTP for the initial Autodiscover Service request so that you do not need to update the subject alternative names list on the reverse proxy certificates. This is your decision based on your organization’s security policies.
      You’re right, WAC listens on port TCP443 (HTTPS). This post describes the steps to configure that as well.

  5. LeBricoleur

    hello
    can you help me
    i try to configure IIS ARR for external acces to exchange server 2013
    i have ise this link :
    http://blogs.iis.net/erez/archive/2013/11/27/installing-arr-manually-without-webpi.aspx

    http://www.microsoft.com/web/downloads/platform.aspx

    http://blogs.technet.com/b/exchange/archive/2013/07/19/reverse-proxy-for-exchange-server-2013-using-iis-arr-part-1.aspx

    https://y0av.me/2013/07/22/lync2013_iisarr/

    but impossible to pass healt check

    i have this error :

    result : failed
    détails : cannot connect to the server. The HTTP status code is 0 and the error code is 80072F8F

    can you help me?

      • Putting the health test aside, what are you getting when trying to navigate to your /owa page from the internet?
        Do you have the internal Root CA installed on the ARR server?

      • i have this error :

        result : failed
        détails : cannot connect to the server. The HTTP status code is 0 and the error code is 80072F8F

        when i navigate to owa ( contacts/email/calendar) i have no probleme

        the certificate is installed on the ARR Server

      • mholtkamp

        I have the same problem after updating exchange 2013 to SP1. Health test error and when i navigate to te owa url i get the bad gateway error (502.4)

  6. lebricoleur974

    i have this error :

    result : failed
    détails : cannot connect to the server. The HTTP status code is 0 and the error code is 80072F8F

    when i navigate to owa ( contacts/email/calendar) i have no probleme

    the certificate is installed on the ARR Server

  7. @y0av =>

    i have this error :

    result : failed
    détails : cannot connect to the server. The HTTP status code is 0 and the error code is 80072F8F

    when i navigate to owa ( contacts/email/calendar) i have no probleme

    the certificate is installed on the ARR Server

  8. Bill H

    Hopefully someone finds this comment helpful. I have been struggling getting this to work with Server 2012 R2 as the reverse proxy. Turns out under 2012 R2 the alternate port settings you define when configuring your servers farms are not saved to applicationhost.config! For those of you not familiar with applicationhost.config, it’s an xml configuration file locate at %WINDIR%\system32\inetsrv\config. You can either edit applicationhost.config directly, or use appcmd (in %WINDIR%\system32\inetsrv\) to add them. To add manually, edit the webfarm, this is what’s created by IIS Manager:
    <webFarm name=”testServerFarm” enabled=”true”>
    <server address=”testServer” enabled=”true” />
    </webFarm>
    Modify like so:
    <webFarm name=”testServerFarm” enabled=”true”>
    <server address=”testServer” enabled=”true” >
    <applicationRequestRouting httpsPort=”4443″ httpPort=”8080″ />
    </server>
    </webFarm>
    You can also use appcmd.exe to do the same thing (although it takes as much typing as editing the config manually, though I guess there is some validation and that could keep you out of trouble!):
    %windir%\System32\inetsrv\appcmd.exe set config -section:webFarms -[name=’testServerFarm’].[address=’testServer’].applicationRequestRouting.httpsPort:4443
    %windir%\System32\inetsrv\appcmd.exe set config -section:webFarms -[name=’testServerFarm’].[address=’testServer’].applicationRequestRouting.httpPort:8080
    Took me about 3 weeks to figure this out, but at least my Lync Server 2013 environment can now be considered “supported” … a couple NAT rules seemed so much simpler!

    • Craig Martland

      @Bill H Your are a legend, i had been stuggleing with my inctall all week and this has been the big problem, i suspected it was the issue but had no idea how to check it. thankyou so much!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

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

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s