Technically Lync: Reverse Proxy Alternatives

Microsoft Lync UC requires several server roles. These different server roles take care of communication modalities such as instant messaging, presence, voice, video, persistent chat and conferencing; connection management, including remote access and federation; and management and reporting, including monitoring and archiving.

The reverse proxy role is one of the Lync supporting roles that's needed to enable a complete remote Lync experience. Some of the key features that the remote proxy enables include:

• Allowing external users to download meeting content
• Enabling remote users to download files from the Address Book service
• Letting external participants access the Lync Web App client
• Providing access to the dial-in conferencing Web page
• Enabling mobile applications to automatically discover and use mobility URLs from the Internet

In general, a reverse proxy server accesses resources on behalf of a client from one or more servers and then returns these resources to the client as if they came directly from the server itself. A reverse proxy serves a security role in that it can "hide" the existence or attributes of key servers. It can also assist in load balancing to distribute the load from incoming client requests across multiple servers.

In the past, many Lync installations relied on Threat Management Gateway (TMG) which had to be purchased separately. However, in November 2012, Microsoft ceased license sales of TMG 2010. While Microsoft still supports the product, you might want to consider using a reverse proxy alternative instead.

And with that overview out of the way, I turn it over to my more technical colleague Dino Caputo. Dino is a Microsoft Certified System Engineer (MCSE) as well as a Microsoft Certified Technology Specialist (MCTS) in LCS 2005, OCS 2007, Lync 2010 and 2013. In summary, Dino knows lots about successfully deploying Lync.

Over to Dino ...

I've reliably been using Internet Information Server Application Request Routing (IIS ARR), free with Windows Server, as a low-cost replacement for ISA/TMG for some time now; however, I recently had a customer that had provisioned Windows Server 2012R2 so I decided to use IIS ARR 3.0 instead of 2.5, which is what I've always used for previous installations. (According to Microsoft, "[IIS ARR] ... is a fully tested and supported option for implementing a reverse proxy for Lync Server 2010 and Lync Server 2013.")

I found some good information on this subject available at NextHop, which I've always followed and has served me well.

On the surface, IIS ARR 3.0 looks identical to Version 2.5; however, I ran into many challenges with rules not processing in 3.0 as expected under 2.5. After much trial and tribulation, I ended up deleting all my rules, starting from scratch and coming up with a different configuration by combining some lessons learned from Lync MVP Richard Brynteson's post.

Based on my experience, I share the process that worked well for me in the hope that it can perhaps help a few other folks along the way:

• Start with a fresh installation of Windows Server 2012 R2 and install IIS from Server Manager. In this case I had a single NIC server that joined to the domain and the corporate network. I enabled the Windows firewall and configured the external Firewall to allow ports TCP 80 and 443 inbound in a 1:1 NAT configuration.
• Download the Microsoft Web Platform Installer (currently 5.0) and search for IIS ARR 3.0. Select it and install it.
• Open IIS Manager, and the fun begins!

Initial Setup

You'll need to make the following modification to the IIS Application Pool for the default Website, which will force the application pool not to shut down after idle minutes. Change the highlighted "Max Time-out" value to 0 as shown below.

 

 

You'll need to provision an SSL certificate from a public provider that will contain all the URLs required for Lync, Office Web App and potentially Exchange Server OWA. (I haven't gone into too much detail or the process of provisioning the certificate as I assume readers understand what these URLs are.)

Bind this certificate in IIS like you would any other secure Website. Choose the Default Website, and select Bindings in the action tab on the right. Click on Add and add a binding for Port 443. Select the certificate you provisioned and installed on this server.

 

Next, we can start building out the Server Farms. In the IIS manager, if you installed IIS ARR correctly, you will see "Server Farms" as a new option in the left pane.

You want to highlight it and right click and select "New Server Farm."

First, we start with creating the Lync Autodiscover farm that will handle requests for Lync Autodiscovery to work. 

  

Click Next, and configure the settings as follows, adding in the FQDN of the internal Lync front end server or enterprise front-end pool that will handle this request. Be sure to change the options as shown below as is required by Lync. Specifically, we use httpPort 8080 and httpsPort 4443 

 

Click "Finish." You'll be prompted to create IIS re-write rules to which you want to say "Yes." We'll address these a bit later.

Create another server farm for each external Web service you need to publish. If you're publishing for two pools, you'll need to create two farms in the same way outlined above.

Create a Server Farm for Office Web Apps in the same way as above, except use the default Port 80 and 443 for the Office Web App server. If you have a pool of Office Web App Servers you can add each server in a single farm.

The results will look something like this when done: 

 

 

 

 

For each server farm you created, click on the server farm and make the following changes to highlighted items:
Disable "Caching" for each farm.
Change the timeout values to 600 seconds in the "Proxy" settings. (This alleviates sign outs on the mobile clients, especially with Android devices.)
Lastly, under "Routing Rules," deselect the "Use SSL Offloading" option. If you fail to do this, you will not see the URL Rewrite rules created.

URL Rewrite Rules

Select the IIS Server name and double click the "URL Rewrite" option highlighted in the below screenshot.  

 

 

You'll be presented with a total of two rules for every server farm you created. So if you created four server farms, you will see eight rules created. Delete all the rules that do NOT end in _SSL.

Office Web App URL Rewrite

Open the Office Web App rule that was created. The names will match the server farm names. Configure it in the following way: 

 

 

Use the regular expression pattern ((?:^en-us/|^hosting/|^m/|^o/|^oh/|^op/|^p/|^we/|^wv/|^x/).*) where shown in the previous screen capture.

Lync AutoDiscover
To configure the autodiscover rule, use the regular expression pattern of (.*) but then add the condition that {HTTP_HOST} matches the pattern of all the SIP domains for which Lync Server is responsible. So if you had three domains, called contoso.com, acme.com and tailspin.com, you can list them in separate lines or simply create them in one rule as follows:  

{HTTP_HOST] Matches the Pattern

 

 

Lync External Web Services

For each front-end pool you must create a URL rewrite that corresponds to the server farm created in the first part of this setup.

This time you'll need to add two conditions:

{HTTPS} matches the pattern ON since we want to support HTTPS only in the Lync Web Service requests

and

{HTTPS_HOST} matches the pattern of your external Web service URL along with all the other Lync Simple URLs required for your front-end pool.

In this case I have: 

 

 

 

Repeat this for all other farms substituting the main Web service URL for the unique URL for each pool. You can leave the other names in the list since they would only trigger if the previous rule is skipped in the event the first server pool is down, for example.

Some Final Notes

• IIS ARR rules are order dependent and will run from top down until a condition is met. By default, once a rule is triggered the execution of rules will cease.
• I find after making changes I do an IIS RESET /restart to speed up the process of changes taking effect.
• You can turn off Server Farms or disable servers within a farm if you are testing rules out and need to troubleshoot your settings. This helps second guessing on which rule is doing the processing.
• If you use a multi-NIC server you'll still need to designate the NIC facing the public Internet as the default gateway and use persistent routes to the internally connected NIC.
• This can be done to a domain-joined machine or a non-domain joined machine. If using a non-domain joined machine you'll need to use a host file to resolve the names of the servers in each of the farms you create. You'll likely need to do this for a multi-NIC machine that uses DNS configuration pointing to public DNS.

Now back to Kevin ...

If you've gotten this far, then you're most likely technically inclined or you just skimmed the above details. In either case, it should be clear that successfully setting up a Lync voice and UC environment requires expertise and experience. Make sure you have both on your implementation team.

As the Lync ecosystem continues to grow, you have an increasing number of choices and more paths that can lead to success - perhaps also an increasing number of paths that can cause pain. When choosing a reverse proxy solution, or any other Lync option, you need to take the time to define your specific business requirements and business priorities, evaluate the pros and cons of the various solutions and then move forward with the best fit for your organization.