Brought to you by the Microsoft Lync Server Documentation Team

Lync Server 2010 Geographically Dispersed Edge Topology: Part 1

Lync Server 2010 Geographically Dispersed Edge Topology: Part 1

  • Comments 16
  • Likes

Deploying Microsoft Lync Server 2010, Edge Servers across a multiple-location organization presents numerous challenges. Lync Server 2010 gives remote users, who are not using a Virtual Private Network (VPN) connection, the ability to take advantage of the same Lync Server 2010 features as users on the local network. Edge Server is the server role that enables this functionality. The Edge Server contains roles such as the Access Edge, Web Conferencing Edge, and Audio/Video Edge. Each role acts to proxy data or media to different destinations. This article walks you through a scenario that explains Edge Server roles and how traffic flows between Edge Servers located in different locations.

Author: Byron O. Spurlock

Publication date: May 15, 2012

Product version: Microsoft Lync Server 2010

In Lync Server 2010, server roles perform specific functions. For example, the Front End Server provides IM and presence, web conferencing, user authentication and so forth. The Edge Server enables remote workers to access instant messaging, presence, audio/video, and web conferencing without using a Virtual Private Network (VPN).

As Edge Server deployments become more common, it’s import for administrators to understand the paths that protocols follow in various user scenarios—especially remote-to-remote scenarios. This article explores a scenario where two remote users, in different geographic locations, within the same Lync Server 2010 organization, communicate through an Edge Server topology.

A consolidated Edge Server delivers the following services:

Access Edge service: Manages SIP traffic for signaling and instant messaging.

Web Conference Edge service: The Persistent Shared Object Model (PSOM) protocol enables Microsoft Office Live Meeting 2007 conferences.

A/V Edge service: The Simple Traversal of UDP through NAT (STUN)/Traversal Using Relay NAT (TURN) protocols traverse firewalls and NATs.

Sample Edge Server Environment

In this Edge Server environment, Contoso has data centers deployed in Redmond and Singapore. Each office is considered the primary user location for that region. Each location has an existing Lync Server 2010 pool that is deployed and functional.

Redmond and Singapore each house a data center that contains a Lync Server 2010 pool with an Edge Server deployed in the perimeter network. The Edge Server topology allows remote users in Redmond and Singapore to collaborate with internal users in either pool with all modalities—IM and presence, conferencing, application sharing, and audio/video. Remote traffic is kept regionalized whenever possible.

Scenario – Lync-to-Lync Calls in Different Pools

Two users, homed in different Lync pools, call each other using Lync 2010 while working from home. User1, Red-Redmond-U1, is located in Redmond and User2, Sing-Redmond-U1, is located in Singapore. In the diagram to follow we will take a look at the call setup and flow of a Lync call.

Figure 1. Redmond user sign in

1. Red-Remote-U1 signs in to the Redmond Lync pool through Redmond Access Edge Server. Because the user is remote and not leveraging VPN, the Lync 2010 client sends a SIP INVITE that contains the Red-Remote-U1’s credentials to the Edge Server over NTLM. The SIP OK will contain valid MRAS information to setup the call.

2. The Redmond Edge Server proxies the remote connection to Redmond Director.

3. The Redmond Director authenticates the remote user and proxies the connection to the user’s home pool which is Redmond pool.

Note: In a Lync-to-Lync call with remote users, the first connectivity attempt is from the internal IP address of each user. The private IP address of each client’s network interface card is passed to each other in the Interactive Connectivity Establishment (ICE) candidate exchange process. If the internal IP address is not available, the connection is relayed through the reflective IP, which is the public IP address of the home router. If the reflective IP address is not available, the media relay address of the Audio/Video Edge Server, of the user who initiated the call is leveraged.

Figure 2. Singapore user authentication

1. Sing-Remote-U1 signs in to the Singapore Lync pool through Redmond Access Edge Server. Because the user is remote and not leveraging VPN, the Lync 2010 client sends a SIP INVITE that contains the Sing-Remote-U1’s credentials to the Edge Server over NTLM. The SIP OK contains valid MRAS information to setup the call.

2. Redmond Edge Server proxies a connection to the Redmond Director

3. Redmond Director authenticates Sing-Remote-U1 and proxies connection to the Singapore Lync pool, which is the user’s home.

Call Flow -Internals

1. Red-Remote-U1 initiates a call to Sing-Remote-U1

Figure 3. Call SIP trace

Note: The example IP addresses used in figures 4 and figure 5 are:

  • Local IP:
  • Reflective IP:
  • Relay IP:

2. Sing-Remote-U1 and Red-Remote-U1 exchange candidate information that contains the relay address of the Audio/Video Edge public interface. The caller, Red-Remote-U1, initiated the call to the callee, Sing-Remote-U1, and begins the ICE protocol connectivity checks to determine the best media path. In this case, the Redmond Edge Server.

3. Sing-Remote-U1 and Red-Remote-U1 both exchange candidate information for each other in order to connect using the most direct route.

Figure 4. Call SIP trace

4. Sing-Remote-U1 and Red-Remote-U1 both exchange candidate information for the local IP, reflective IP and the Relay IP of the Audio\Video Edge public interface. The following process is depicted in the Figure 5 below; the example addresses that are used are included: (only the trace that coincides to this step is shown.

5. The caller (Red-Remote-U1) was the initiator of the call to the callee (Sing-Remote-U1) and begins the ICE protocol connectivity checks to determine the optimal media path, which is the Redmond Edge Server. The process below depicts the result of the candidate check and the identification of the Edge Server being used for the call.

Figure 5. Call SIP trace

In our scenario it is assumed that both users cannot connect using the following methods:

  • UDP direct: UDP ports of each user’s computer IP addresses.
  • UDP NAT: Connecting through the reflexive IP address of the public IP address of the home router for each Lync user.

Note: When you configure your Lync 2010 pool in Topology Builder, you can configure which Edge Server pool the Lync pool will communicate with. Because the Lync 2010 organization contains a single entry point (SRV Record) for remote access, it is responsible for all SIP communication through the Access Edge Server(s) located in the Redmond data center.

Figure 6. Edge Server configuration.

Figure 6 displays Topology Builder configuration where the administrator associates an Edge Server to a pool.


When deploying geographically disbursed Edge Servers, the key takeaways are:

  • Access Edge is responsible for proxying SIP traffic for remote clients to the next hop, which can be a Director or a Lync pool.
  • The initiator of the call broadcasts multiple methods to establish the call to the callee.
  • Lync clients attempt to communicate using the most direct path which is peer to peer. If that fails, the public interface of the home router and the Edge Server are leveraged last.
  • Topology Builder allows administrators to select the respective Edge pool for Lync pool.

Lync Server Resources

We Want to Hear from You

  • Excellent explanation, I was wondering though how federation routes would work with that?  If multiple edge pools are capable of federation, is there a recommendation on how to configure that traffic?

  • Interesting topic, and one which we touch on regularly in my organization.

    That being said, it is sad that Microsoft does not support geo-ip solutions to ensure that external users are directed to the edge closest to them regardless of what pool they are assigned to.  Please consider updating your supported topologies to include external geo-dns solutions.

  • Kswail thanks for comment, note taken about updating supported topologies regarding Geo-DNS solutions.

  • Really nice! It is a "must to know" for all Lync engineers!

  • Excellent article .Edge deployment is an integral part of Lync deployment . Thanks

  • Thanks for the comments.  

  • Really glad to see so much interest in this article. Part 2 is in the works. Great job, Byron!

  • Byron, does this assume both sites are in the same Lync 2010 site or different sites? If they are in different sites, what is the assumption on how "remote traffic is kept regionalized whenever possible."

  • In this scenario the Redmond and Singapore deployments are in different sites. Remote traffic is kept regionalized for Web Conferencing and Audio\Video traffic for the respective pools.  Once a client signs in they are passed through to their respective pool.  Each Lync Front End pool has a corresponding Edge pool it is associated with, done through Lync topology builder. After the client signs into Lync they are passed (through in band provisioning) the Edge server information to allow the client to leverage the Edge server assigned to users pool.  By this process, for two pools that are separated geographically users in the respective pools will utilize the Edge server to allow "remote traffic" to stay regionalized.  Now there is the possibility where two users in separate pools hold a conversation with each and the traffic is not regionalized, but that occurs with core Lync scenarios as well, for example Lync conferencing.

  • Byron, there is a typo in the user names right at the beginning.

    It would be also nice to describe a scenario where the central signalling and local media Edge servers are used - for p2p and conferencing calls. Federation would complete the picture.

  • could you tell where I can download VISIO charts I see on your blog, please, I would be very helpful. I leave you my email in case you send it to me.

    c.moreno.reymundo @


  • Would you advise the Singapore Pool to use the Singapore Edge for media components and have the Redmond Pool use the Redmond Edge for media components or should all Pools use the same Edge Pool for media?



  • I have been asked to provide federation between my and another company. Am new to federation. my infrastructure does not have any Edge servers deployed. We have Site-to-Site VPN connection with the company. Do I need Egde server in the DMZ to facilitate this?

  • @Kojo

    Here are links to the federation topics on TechNet:

    Planning for External User Access

    Deploying External User Access

    Here is a blog post about this:

    Microsoft Lync federation enables cross-organization communications

    I suggest you post your question in the Lync forums as well:  

  • If I have two Enterprise pools and a single Edge, do I need a director to proxy connections from one pool to the other? Or do the pools automatically share the Edge server and forward connections whenever needed?

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment