The Lync Edge Server is an often misunderstood server role that in theory is not all that complicated.  But without knowing some of the basic functionality provided it can be confusing at times to understand what traffic is going where in the topology.

This article takes a look at the services and network traffic which travels to, and through, the Edge Server in an effort to simplify deployment and troubleshooting by gaining a basic understanding of the Edge Server’s purpose.

Edge Services

Before looking at the individual ports it is important to understand that the Edge Server is comprised of five different Windows Services which are responsible for handling different types of traffic and requests.

To identify the services and their names perform either of the following actions:

• On the Edge Server open the Windows Command Prompt and issue the “net start | findstr Lync” command to list the installed services on the Lync Edge Server.

net start | findstr Lync

• Or use the Services Control Panel applet to view the installed services.

When troubleshooting it is helpful to know the basic Service Name and well as the core application for each of the Edge services.

Listening Port Allocation

The following diagram is a slight modification from the Port Summary for Single Consolidated Edge documentation in TechNet.  The Reverse Proxy server was removed as well as the outbound connections for DNS and HTTP, leaving only the inbound listening ports required on the Edge Server depicted.

As shown above there are multiple ports utilized by the Edge server with some of the same port numbers (e.g. 443) assigned to multiple interfaces.  Simply looking at the port number alone is not enough to know what type of traffic might be associated with it as different services will use the same port number for different purposes, albeit on different IP addresses as no two services can occupy the same listening port on the same IP address.  Thus it is important to always note the IP address of the interface as well as the port.  For example, traffic sent to the internal IP of the Edge server over port 443 would be for relaying media, but traffic sent to the Access Edge external IP over port 443 would actually be external client SIP signaling requests.

Example Configuration

For the remainder of this article the following Lync Server Topology is used throughout all example text and screenshots.

Querying Listening Ports

To verify that the proper ports are listening and the Edge services are functional the following validation checks can be performed.

• On the Edge Server open the Windows Command Prompt and issue the “netstat -an” command to list all of the currently open network ports on all interfaces.  (The -a switch returns open listening ports as well as any ports with established connections.  The -n switch skips reverse name lookup on any host IP addresses and will allow the command to complete much faster.)

netstat -an

Among the results of all static and dynamic ports for any service or application on the server the specific Lync Server listening ports for the various Lync Edge services should be displayed. Note that some of these IP:Port combinations may display multiple entries as an active Edge server will have server and client connections. But the additional entries should all be reported as in an Established state and only a single line for each will be in a Listening state.

The following entries were pulled from the command output and listed in a table for easy identification.

Proto   Local Address             Foreign Address      State   
TCP     0.0.0.0:4443              0.0.0.0:0            LISTENING
TCP     10.4.5.11:443             0.0.0.0:0            LISTENING
TCP     10.4.5.11:5061            0.0.0.0:0            LISTENING
TCP     10.4.5.11:5062            0.0.0.0:0            LISTENING
TCP     10.4.5.11:8057            0.0.0.0:0            LISTENING
TCP     140.2.21.9:443            0.0.0.0:0            LISTENING
TCP     140.2.21.9:5061           0.0.0.0:0            LISTENING
TCP     140.2.21.10:443           0.0.0.0:0            LISTENING
TCP     140.2.21.11:443           0.0.0.0:0            LISTENING
UDP     10.4.5.11:3478            *:*
UDP     140.2.21.11:3478          *:*

What the results above show are all of the static listening ports used by the various Lync in an unconnected Listening state. The Protocol is shown as TCP for all ports except for 3478 UDP on the A/V Edge external IP address which is used for connectionless traffic from Lync clients and servers to the Media Relay service. The Foreign Address of 0.0.0.0:0 is shown as these are open listening ports with no connections established. Any established connections to these ports will be reported by netstat in additional lines.

The netstat command also provides a switch to display the executable name for each opened port to assist in identification of the which service owns which listening port.

• On the Edge Server open the Windows Command Prompt and issue the “netstat –abn” command to display the same output as before but with additional lines showing the service program file name. (The -b switch adds the service names to the output for each port.  As shown in the example the individual switches can be concatenated so both -abn and -a -b -n are valid formats.)

netstat -abn

By matching up the reported executable names in the results the following table can be created, indicating what type of connections each port is listening for.

A closer look at the table above identifies some important concepts:

• The CMS replication agent listens on all interfaces on the Edge server, presumable to assist in data replication in the event that the Edge Server configuration or routing is not configured to best practices.  In a proper deployment these connections would be coming from an internal Lync server directly to the Edge internal interface.
• The Audio/Video Edge (Media Relay) services listens on both interfaces, as it must do so to proxy media connections between internally connected clients and external clients/servers.
• The Web Conferencing Edge service also listens on both interfaces as it proxies web conferencing traffic between external clients and internal Front End servers.
• The Audio/Video Authentication service listens only on the internal interface.  All client connections to this service are to provide dynamically assigned credentials to the Edge server to utilize ICE and access the media proxy as the Edge server will not accept connections from just any hosts.  Because the Access Edge Server cannot authenticate Lync users and must pass all authentication traffic through into the internal servers then it in turn also cannot authenticate ICE connections from these same users.  Thus call client ICE authentication attempts are proxied through an internal Lync server (Front-End or Director) which has already authenticated the client connection.  This means that all of these authentication attempts to the Edge Authentication service will always come from an internal Lync server, and not directly from any internal or external clients.  This is the reason that the A/V Edge FQDN (e.g. av.domain.com) is not needed on the external Edge certificate as the internal Lync servers will connect to the internal Edge interface (e.g. 10.4.5.11) using the internal Edge FQDN (e.g. edge.domain.local).

Media Port Range

If the listening ports in the table above are compared back to the original diagram there is still one last traffic type left unaccounted for: the 50,000-59,999 port range used for media traversal.

It is important to understand that this port range is only opened on the external A/V Edge interface, not the internal interface. All internal Lync clients and servers will tunnel media directly to either 3478 (UDP) or 443 (TCP). This many-to-one model is possible because of the deployment requirement that Network Address Translation (NAT) is not allowed between the internal Edge interface and any internal subnets hosting clients and servers. Thus every inbound connection to either 443 or 3478 would contain a unique IP address and source port.  Whereas on the external side of the Edge server the remote hosts could be behind NAT or multiple federated Edge servers could be attempting to open connections from the same source port.  In OCS R2 the ability to tunnel external media connections was added but this is only for UDP media and not TCP, thus is is still recommended to allow inbound connections form the Internet to this entire port range for both UDP and TCP traffic.

For a more detailed demonstration of exactly what these ports are used for and why it is recommended to still allow this range of ports inbound then jump to 1:04:00 of the Edge Media Connectivity with ICE technical session from TechEd 20102.

These ports are not constantly open for listening as they are allocated on-demand as the media relay service needs to.  When external and/or internal clients need to proxy media through the Edge Server then listening ports will be allocated during media negotiation between endpoints.  Once the best path for media has been established (which may not actually be through the Edge Server) then any unused ports where were allocated for that call are released.  When viewing port allocation with netstat a large number of ports between 50.000 and 59,999 may be displayed for both TCP and UDP protocols.

• On the Edge Server open the Windows Command Prompt and issue the “netstat –anp tcp | findstr :5” command to return only listening and established TCP ports beginning with a 5.

netstat -anp tcp | findstr :5

• On the Edge Server open the Windows Command Prompt and issue the “netstat –anp udp | findstr :5” command to list only listening and established UDP ports beginning with a 5.

netstat -anp udp | findstr :5

Testing Listening Ports

• From a remote host on an internal network (e.g. a Lync Front End Server) open the Windows Command Prompt and issue the telnet command to one of the internal Edge services.  (If the telnet client is not found then it must first be installed on the Windows Host.)

telnet edge.domain.local 5061

If a connection to the port fails this would indicate a problem like the service is not started or listening on the Edge server, the Edge server is unreachable due to a firewall or other port filtering or routing issue, or name resolution has failed.

The expected response would be to see the command prompt window immediately refresh and a blank window will be displayed. (When testing connections to the internal IP to TCP 8057 for Web Conferencing a string of seemingly nonsensical characters will be turned instead of a blank window, this is normal.)





• Leaving the telnet session open on the remote host move back to the Edge Server and issue the following command to look for the specific connection.

netstat -an | findstr 5061

As this deployment includes a Director server (10.2.10.25) existing established connections already appear to the Edge server over TCP 5061 from the assigned next-hop server, while the test telnet connection from the Lync Front End (10.2.10.27) is easily identifiable in the results.

This same test can be performed for any of the TCP listening ports on the Edge server, but not the UDP listening ports as the connectionless UDP protocol is not compatible with Telnet.  If it is attempted there will be no response from the server on the 3478 UDP ports listening on both sides of the Edge Server.

A randomly selected TCP listening port in the 50,000-59,000 range can also be tested but the Edge Server will actively refuse the connection.  This result illustrates why the media range ports cannot be connected to or port-scanned under normal circumstances.

• View the list of currently listening TCP ports and select one at random (e.g. 50137)



• From a remote host attempt to telnet to that same port and see that the connection is refused almost immediately.



This is because when the Telnet client connects it is neither the type of connection the Edge Server expects nor are the proper credentials available to provide to the media relay service to allow the connection to be established.