locked
Lync Edge & TMG Reverse Proxy RRS feed

  • Question

  • We have deployed Lync and an Edge server and it works fine. After doing a bit of reading we found out that if need to deploy a reverse proxy: - 

    • To allow users to connect to meetings or dial-in conferences using simple URLs 
    • To enable external users to download meeting content
    • To enable external users to expand distribution groups
    • To allow the user to obtain a user-based certificate for client certificate based authentication 
    • To enable remote users to download files from the Address Book Server or to submit queries to the Address Book Web Query service
    • To enable remote users to obtain updates to client and device software
    • To enable mobile devices to automatically discover Front End Servers offering mobility services
    • To enable push notifications to mobile devices from the Office 365 or Apple push notification services

    We plan on deploying TMG to use the Reverse Proxy functionality, can this be installed on the Egde server or does it have to go on its own host? I will admit I am struggling to see how it all works as the publised external website points to the Edge. Will this need to change and point at TMG, if it does how will external clients talk with the Edge for 

    • Access Edge service   The Access Edge service provides a single, trusted connection point for both outbound and inbound Session Initiation Protocol (SIP) traffic.
    • Web Conferencing Edge service   The Web Conferencing Edge service enables external users to join meetings that are hosted on your internal Microsoft Lync Server 2010 deployment. 
    • A/V Edge service   The A/V Edge service makes audio, video, application sharing, and file transfer available to external users. Your users can add audio and video to meetings that include external participants, and they can share audio and video directly with an external user in point-to-point sessions. The A/V Edge service also provides support for desktop sharing and file transfer. 

    Thanks

    Wednesday, March 28, 2012 1:23 PM

Answers

  • TMG must be installed on a separate host, it cannot be collocated with the Edge server.  Each server provides access to two completely separate sets of services.

    The Edge server handles client connections to the three Edge roles (Access Edge, Web Conf, A/V Edge) and traverse ports like 5061, 443 (for SIP), 8057, 3478, etc).  Once the external Lync client is able to successfully SIP-register to the Access Edge server then the server pass in-band the rest of the Lync topology information, including the External Web Services FQDN.  The client uses this unique FQDN (different from the Access Edge FQDN) to attempt connections to the Lync Web Services for any of the features you stated in your first list.  The External Web Service FQDN is pointed to your TMG web listener which publishes the web services running on your Front End servers.

    So:

    1. External clients autodiscover (e.g. sip.domain.com) and connect to the Edge server over SIP which tunnels traffic to the Front End service (rtcsrv) on the internal Front End server.
    2. External clients are passed the External Web Services FQDN (e.g. lyncweb.domain.com).
    3. External clients attempt a connection over TCP443 to the External Web Services FQDN, which is directed to the Reverse Proxy.
    4. The Reverse Proxy (e.g. TMG) proxies this connect back to the web services (IIS) on the internal Front End server.

    Hopefully this clears up the confusion and you can see that we are talking about two separate types of communications (SIP vs. HTTPS) routed over different proxies (Edge vs. TMG) back to different core services (rtcsrv vs. IIS).


    Jeff Schertz | Microsoft Solutions Architect - Polycom | Lync MVP

    • Proposed as answer by Kent HX Thursday, March 29, 2012 5:30 AM
    • Marked as answer by Sharon.Shen Monday, April 2, 2012 2:39 AM
    Wednesday, March 28, 2012 1:45 PM
  • Hi Paul,

    1. You shouldn't install reverse proxy server role on edge box , it should a seperate host.
    2. All reverse proxy requests mentioned above , should be pointed to TMG external interface. You can create a website publishing rule to forward that traffic to FE pool.
    3. Edge box (Consolidated) will proxy SIP registration, AV/Web traffic for external users.

    Hope this helps.

    Thanks

    Saleesh


    If answer is helpful, please hit the green arrow on the left, or mark as answer.

    • Proposed as answer by Kent HX Thursday, March 29, 2012 5:30 AM
    • Marked as answer by Sharon.Shen Monday, April 2, 2012 2:39 AM
    Wednesday, March 28, 2012 1:36 PM

All replies

  • Hi Paul,

    1. You shouldn't install reverse proxy server role on edge box , it should a seperate host.
    2. All reverse proxy requests mentioned above , should be pointed to TMG external interface. You can create a website publishing rule to forward that traffic to FE pool.
    3. Edge box (Consolidated) will proxy SIP registration, AV/Web traffic for external users.

    Hope this helps.

    Thanks

    Saleesh


    If answer is helpful, please hit the green arrow on the left, or mark as answer.

    • Proposed as answer by Kent HX Thursday, March 29, 2012 5:30 AM
    • Marked as answer by Sharon.Shen Monday, April 2, 2012 2:39 AM
    Wednesday, March 28, 2012 1:36 PM
  • TMG must be installed on a separate host, it cannot be collocated with the Edge server.  Each server provides access to two completely separate sets of services.

    The Edge server handles client connections to the three Edge roles (Access Edge, Web Conf, A/V Edge) and traverse ports like 5061, 443 (for SIP), 8057, 3478, etc).  Once the external Lync client is able to successfully SIP-register to the Access Edge server then the server pass in-band the rest of the Lync topology information, including the External Web Services FQDN.  The client uses this unique FQDN (different from the Access Edge FQDN) to attempt connections to the Lync Web Services for any of the features you stated in your first list.  The External Web Service FQDN is pointed to your TMG web listener which publishes the web services running on your Front End servers.

    So:

    1. External clients autodiscover (e.g. sip.domain.com) and connect to the Edge server over SIP which tunnels traffic to the Front End service (rtcsrv) on the internal Front End server.
    2. External clients are passed the External Web Services FQDN (e.g. lyncweb.domain.com).
    3. External clients attempt a connection over TCP443 to the External Web Services FQDN, which is directed to the Reverse Proxy.
    4. The Reverse Proxy (e.g. TMG) proxies this connect back to the web services (IIS) on the internal Front End server.

    Hopefully this clears up the confusion and you can see that we are talking about two separate types of communications (SIP vs. HTTPS) routed over different proxies (Edge vs. TMG) back to different core services (rtcsrv vs. IIS).


    Jeff Schertz | Microsoft Solutions Architect - Polycom | Lync MVP

    • Proposed as answer by Kent HX Thursday, March 29, 2012 5:30 AM
    • Marked as answer by Sharon.Shen Monday, April 2, 2012 2:39 AM
    Wednesday, March 28, 2012 1:45 PM
  • Hi Jeff,

    Your last reply above is a great explanation of users connecting externally using Lync clients. One thing I'm trying to find out is the actual connectivity flow of external users connecting with the Web App for meetings.

    So to be more specific, an external user clicks a meeting URL in Outlook, but does not have any of the Lync clients installed, and selects "Join as Guest" in the Web App. Does this still connect solely through the Reverse Proxy, or does it instead redirect to the Webconf interface on the Edge server? I can't seem to find a step by step communication flow anywhere for external web-app users accessing Lync Meetings in 2013. Seeing as there's now full A/V capabilities, I imagine the web app is somehow redirected to the Edge server for the full UC features.

    Thanks in advance for any input you could provide on this subject.

    Wednesday, January 2, 2013 6:03 PM
  • Any update on the flow here?  We're having issues getting the Lync 2013 Web client to give us the 2013 experience from the outside through our TMG.  We instead get the old 2010 web client.  Internally it works fine, just breaks coming in from the outside.

    Thoughts?


    Bob

    Thursday, February 28, 2013 8:14 AM