Remote Conferencing with Lync Web App with Forefront Threat Management Gateway 2010 Reverse Proxy: Part 1

Microsoft Lync Web App is the new Microsoft browser-based client solution for the Microsoft Lync Server 2010 communication software instant messaging and conferencing features. The Lync Web App client can provide remote user access to internally hosted Lync Server 2010 conferences. This is done by using a reverse proxy configuration that many web proxy server solutions offer. Microsoft Forefront Threat Management Gateway 2010 supports a reverse proxy configuration that can host the remote Lync Web App conferencing client.

This article is the first part of a two-part series that provides you with a step-by-step solution for configuring Microsoft Forefront Threat Management Gateway 2010 as a reverse proxy that provisions remote access for Lync Web App conferencing users. Part two explains the type of network connectivity that is required to adequately use all the conferencing features of the remote Lync Web App client.

This article is being reviewed and updated. We will repost the article when revisions are complete.

Author: Mike Adkins

Publication date: February 2011

Product version: Microsoft Lync Web App, Microsoft Forefront Treat Management Gateway 2010, Microsoft Lync Server 2010


Comments (6)

  1. Seabass says:

    Great article DrRez.  Wish I had run across it earlier.  One interesting thing I came across with publishing through my TMG standard array was that the load balancer in front of the TMG array was splitting off the remote conferencing session so that I could click the link for the meeting, and it would appear to connect successfully, but when I tried to "join meeting", it would error out.  The load balancer was seeing that as a separate request and would route it to the other TMG which in turn would route it to my other FE server (through an internal load balancer).  Anyway long story short…I had the network team put the LB in a failover config so that all traffic routed through one TMG server unless it went down.  This way all requests would take the same path.  Thought I'd share in case anyone runs into the issue.  There may be a better way, but this seems to work well.  Thanks.

  2. DrBeast says:

    Dear DrRez, great article.

    I have publish the LWA thru my TMG. But i have a some issue here, the simple URL for, if i try to signin and get error as follow:

    "The operation failed with an unexpected error. If the problem persists, contact your system administrator"

    do you have article about dialin publishing.?


  3. Mark Brumby says:


    Can you confirm, or supply the reference material to confirm that  a TMG Array can or can’t be

    used to load balance Lync HTTPSTraffic?  instead of a HLB. ?



  4. RNM says:

    Hi Mark Brumby,

    Did you find the answer to your question?   I have the same question


  5. Mike Adkins says:

    Using Windows Network Load Balancing and forefront 2010 TMG

    The Forefront TMG array supports both the use of Windows Network Load Balancing (NLB) and vendor hardware load balancing solutions. For more details review the article listed below:

    Planning for Forefront TMG server high availability and scalability…/dd897010.aspx

    A Windows NLB array is designed to recognize all Version 4 IP addresses. To manage this process Windows NLB will distribute all known IP address ranges evenly across the nodes in the NLB array. The distribution is allocated into "buckets" and each NLB node
    will be the owner of one bucket. This ensures an entry point for each new IP connection request that is managed by the Windows NLB array.

    Windows NLB also provides a "sticky" solution that is known as Affinity. The Affinity configuration helps ensure IP session state between the client and the NLB cluster node for the lifetime of a NLB session. Also, the Affinity, Single option specifies that
    Network Load Balancing should direct multiple requests from the same client IP address to the same cluster host.

    Please read the – Affinity on the Add/Edit Port Rules dialog box – section of the article listed below

    Network Load Balancing parameters…/cc778263(WS.10).aspx

    The remote Lync Web App client will make separate TCPIP connection requests to the reverse proxy solution that is hosting the internal   external Lync Server 2010 Web Services solution as it steps through its sign in process. I feel that as per the documentation
    listed above the remote Lync Web App client should be able to keep a static connection to a single node in the NLB array that will consists of separate TCP sessions.

    Things to check:

    Make sure that your Windows NLB configuration includes the needed Affinity configuration

    A NAT solution that is in anywhere in front of the Lync Web App client could be configured to provide source IP address information for the separate Lync Web App TCP sessions from a pool of IP addresses. This is one reason that the Windows NLB configuration
    listed above could possibly route a subsequent Lync Web App connection requests to a different node in the Windows NLB array.

    Remote Lync Web App needs to access

    You can update the Lync Web App  Forefront 2010 TMG web publishing rule to accept requests for the Lync Server 2010 dialin URL. As follows:

    A public DNS host record entry will have to be added to the DNS solution that will be used by the remote Lync Web Add client. See the” Public DNS solution” section of the article

    The certificate that is applied to the Lync Web App web publishing rule will need its SAN list updated to contain See the “Certificate Solution” section of the article

    The Lync Web App web publishing rule will need to have the FQDN of added to the Web sites and IP addresses window on the Public name tab. See figure 11 in the article.

    By updating the Lync Web App web publishing rule as described above you should be able to access the  Lync Server 2010 dial in information from a browser on the remote client computer and through the remote Lync Web App client on that same computer. The
    same user authentication rules will be applied for both types of request to access

  6. I know that the post is old, anyway, you need to enable the option to “Forward the original host header instead of the actual one specified in the Internal site name field on the previous page” when creating the Reverse Proxy Web Publishing rule.

    If you don't do that, you have a blank page calling meet, dialin and so on.

    The correction is from the  Jamie Schwinn blog…/lync-host-header-forwarding

Skip to main content