Check out the most comprehensive, actively managed Lync blog roll in the known universe, your one-stop source for links to over 100 of the very best Lync blogs. Here you will also find weekly blog highlights and a feed for a dozen of the top blogs.
Lync Server Support Home
Top Lync Solutions RSS Feed
Microsoft Senior Support engineers walk you through real-life support cases, giving you an insider’s view into the systematic approach they use to troubleshoot Lync Server issues.
These short videos focus on specific tasks and show you how to accomplish them for Microsoft Lync Server 2010.
With Forefront Threat Management Gateway (TMG) 2010 now discontinued, we sought a suitable reverse proxy solution that works with Lync Server. With the release of Windows Server 2008, it is now possible to add an optional component called IIS Application Request Routing (ARR) 2.5 to the Internet Information Services (IIS) role. This component enables IIS to handle reverse proxy requests, URL rewrites, and load balancing, among other features.
Author: Koen Wagenveld, Brandon Consulting Ltd.
Technical Reviewer: Rick Kingslan
Editor: Susan S. Bradley
Publication date: February 19, 2013
Product version: Lync Server 2010, Lync Server 2013, Windows Server 2008
With Forefront Threat Management Gateway 2010 now discontinued, we sought a suitable reverse proxy solution that works with Lync Server. (The Exchange and SharePoint Product Teams do not support IIS ARR today.) With the release of Windows Server 2008, it is now possible to add an optional component called IIS Application Request Routing (ARR) 2.5 to the Internet Information Services (IIS) role. This component enables IIS to handle reverse proxy requests, URL rewrites, and load balancing, among other tasks. For details and download, check out the Application Request Routing page of the Microsoft IIS website.
NOTE: IIS ARR is supported on Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012. It is also supported On Windows Vista, Windows 7, and Windows 8 with the Web services features installed. Also, IIS ARR does not require IIS 6.0 compatibility mode.
So why is a reverse proxy required? Aside from security considerations that arise if you use network address translation (NAT) directly to your Lync Front End Server in your LAN (which is never recommended), this also requires your firewall to do port translation. Lync Server uses two websites to service its web requests, one for the internal network and one for the external network. The external website listens on port 4443, instead of on the standard port 443, thus requiring a reverse proxy to translate between the two, as shown below in Figure 1.
Figure 1. IIS ARR as a reverse proxy in the perimeter subnet
The following points should be true for your deployment:
To start, ensure that the computer you’re using for ARR has its default gateway in your perimeter network and is able to browse the Internet. Also ensure that the machine is not joined to your Active Directory domain. In my example (very similar to the Lync Server Edge server), I use one NIC in the perimeter network and one in the LAN. The ARR computer must be able to receive requests from the Internet and route them to your Lync Server Front End server. For name resolution, you can use an internal DNS server or use the HOSTS file to specify the simple URLs that you’re establishing. For my deployment, I used the following simple URLs:
Ensure that each of these names resolve on the ARR server to your Lync Server Front End server. It’s best to use an additional name for the Office Web Apps external URL, but in this example, I configured Office Web Apps to use the same external URL as our Lync external Web Services. Thus, we don’t have to add an additional name to our SAN certificate.
Important: It is highly recommended that you use a distinct rule for your Office Web Apps server. By default, unlike Lync Server web services, the Office Web Apps server listens on HTTPS/TCP/443 and has a distinct fully qualified domain name and DNS name. Additionally, the suggestions here for the Office Web Apps server rule uses ^en-us/ as part of the rule set. If you support languages other than United States English, this rule may fail.
To install Internet Information Server and the Application Request Routing module, complete the following:
Figure 2. Edit Bindings and assign your certificate to enable SSL/TLS
Figure 3. Specify a Web farm name
Figure 4. Configure properties for the Web farm members
Figure 5. Configure Caching, Proxy, and Routing Rules
Figure 6. Location of the URL Rewrite rules component in IIS
By default for each server farm, an HTTP rule is created. These can be disabled or removed, because we’re interested only in HTTPS.
Figure 7. Edit your rules in URL Rewrite
Figure 8. Ensure that the correct server farm is specified
Figure 9. URL rewrite rule expression and condition for Office Web Apps server
Configured this way, all virtual directories matching this pattern will be directed to our Office Web Apps server and everything else will be directed to the Lync Front End.
The result should approximate what is shown below in Figure 10.
Figure 10. Example URL Rewrite rule set for Lync Server and Office Web Apps server
Figure 11. Example rewrite rules for Exchange web services.
Additionally, make the following changes to fix issues with RPC over HTTP:
Figure 12. Redefine the maximum allowed content length
Figure 13. Adjust Time-out and Response buffer threshold values
To troubleshoot, the best place to start is with the IIS log on the ARR server. Browse to this default folder: %SystemDrive%\inetpub\Logs\W3SVC1.
To see what ARR is actually doing under the hood and to configure Failed Request Tracing, review the article titled, Using Failed Request Tracing Rules to Troubleshoot Application Request Routing (ARR). This process creates XML trace files in this folder by default: %SystemDrive%\inetpub\Logs\FailedReqLogFiles\W3SVC1.
You should now have a single server in your perimeter network, using a single IP address and a single certificate to reverse proxy all Lync workloads, with the option to add Exchange and SharePoint workloads. For highly available deployments, I anticipate that hardware/appliance load balancers will fill the gap and provide similar features in the near future (if not already available).
Keywords: IIS, reverse proxy, IIS ARR, application request routing, TMG, threat management gateway