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:

• Access.exchangelabs.nl (sometimes sip.<YourDomain> is used here)
• Webconf.exchangelabs.nl
• Av.exchangelabs.nl

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:

• Meet.exchangelabs.nl
• Dialin.exchangelabs.nl
• Lyncweb.exchangelabs.nl

Note. The internal name of the Lync Front-End pool is lyncpool.exchangelabs.nl but the external name is lyncweb.exchangelabs.nl. 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 ARR01.exchangelabs.nl.

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 http://www.microsoft.com/web/gallery/install.aspx?appid=ARRv2_5. You can also use ARR version 3 which can be downloaded here: http://www.iis.net/downloads/microsoft/application-request-routing

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 meet.exchangelabs.nl simple URL, but you have to repeat these for the dial.exchangelabs.nl and the lyncweb.exchangelabs.nl 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. meet.exchangelabs.nl) and click Next. Enter the Server address of the internal Simple URL (I’m using split DNS so this is again meet.exchangelabs.nl, 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 meet.exchangelabs.nl server farm again and double click on Proxy. Change the Time-out value from 30 seconds to 200 seconds and click Apply.

Select the meet.exchangelabs.nl 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 dial.exchangelabs.nl Simple URL.

Repeat these steps for the lyncweb.exchangelabs.nl 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: meet.exchangelabs.nl

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:

• https://meet.exchangelabs.nl/Reach/Client/WebPages/ReachClient.aspx (you need Silverlight on your client to do this)
• https://dialin.exchangelabs.nl/dialin/conference.aspx
• https://lyncweb.exchangelabs.nl/Scheduler/Default.aspx

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:

Summary

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.