Technically Lync: Reverse Proxy AlternativesTechnically Lync: Reverse Proxy Alternatives

Using IIS ARR 3.0 on Windows Server 2012 as a Reverse Proxy for Lync Server 2013

In our second article of this series catering to the more technical audience in the No Jitter crowd, we explore the role of and options for a Lync reverse proxy server. (The first Technically Lync article investigated real-time monitoring of your Lync environment.)

Like all unified communications solutions, 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:

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:

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:

Next page: Dino covers Server Farm Settings, URL Rewrite Rules, Office Web App URL Rewrite, Lync AutoDiscover, Lync External Web Services and more.

Server Farm Settings

For each server farm you created, click on the server farm and make the following changes to highlighted items:

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
lyncdiscover.contoso.com|lyncdiscover.acme.com|lyncdiscover.tailspin.com



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:

LyncWebExt01.contoso.com|meet.contoso.com|dialin.contoso.com|
meet.acme.com|dialin.acme.com|meet.tailspin.com|dialin.tailspin.com



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

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. (See The Goldilocks Approach: 7 Steps to Get to "Just Right" for details on how to evaluate options.)

Questions or comments for Dino or Kevin? Feel free to leave a comment below. We will work hard to answer any of your queries.