Useful Tips for Testing Your Lync Server 2010 Edge Server
Published May 20 2019 04:18 PM 953 Views
Occasional Visitor
First published on TECHNET on Dec 07, 2011

Deploying Microsoft Lync Server 2010 Edge Server can be a daunting task. Installing the software is straightforward, but getting every functional element of all the ancillary components configured properly is a challenge. Before the deployment is fully functional you need to solve issues such as firewalls, network capacities, reverse proxy, DNS, routes, certificates, and so forth. This troubleshooting checklist was developed to facilitate a smooth deployment of Edge Server.

Authors : Patrick Kelley with Sebastiaan Poels

Publication date : December 7, 2011

Product version : Microsoft Lync Server 2010

In creating this checklist the following assumptions were made:

  • Lync Server 2010 is fully functional.

  • Edge Server is part of a workgroup and is located in a firewalled DMZ.

  • Lync Server 2010 is in a consolidated configuration.

  • VPN is not being utilized from a client perspective.

  • Lync Server 2010 is deployed with all roles (IM, Conferencing, and AV).

  • Edge Server is deployed and the Lync Server 2010 topology reflects all proper settings.

Note: For an overview of the supported Lync Server 2010 Edge Server deployment strategy please see the following: Edge Deployment Overview .

Step 1: DNS

Table 1 below shows all the DNS entries required for a Consolidated Edge Server.

Note: All names and IP addresses are assumptive.

Table 1. DNS Entries

Because these DNS entries are public, they need to resolve externally for all users. To test this functionality, run a simple NSLookup from any machine on a public network. As an example, Figure 1 is a lookup of Microsoft’s external SRV. Figure 2 shows the A records. All the DNS entries from Table 1 should succeed with the expected IP addresses. Table 1 is a reference table that can be used to check all the required DNS records. When you have verified that all DNS entries are correct, you can move on to Step 2.

Figure 1. NSLookup SRV Records

Figure 2. NSLookup A Records

Table 2 is a list of all required DNS records for a typical Edge Server environment. Verifying that these records exist and resolve publicly, is a critical step for a proper DNS deployment.

Table 2. DNS Records Reference Table




Nslookup from the External client

Nslookup for Access Edge
( )

Reply with the external IP
of your Access Edge interface


Nslookup your Web Conferencing Edge
( )

Reply with the external IP
of your Web Conferencing interface


Nslookup for AV edge

( )

Reply with the external IP
of your AV Edge interface


Nslookup for Meet Simple URL

( )

Reply with the external IP
of your Reverse Proxy interface

Simple URL

Nslookup for Dial-In Conferencing Simple URL

( )

Reply with the external IP
of your Reverse Proxy interface

Simple URL

Nslookup for Lync External Web Farm

( )

Reply with the external IP
of your Reverse Proxy interface

Lync Web Services

Nslookup for Open Federation Discovery

( _sipfederationtls._tcp.

Reply with a SRV record pointing to the Access Edge interface on port 5061


Nslookup for Automatic sign-on

( _sip._tls.

Reply with a SRV record pointing to the Access Edge interface on port 443

Nslookup from the Lync 2010 Edge Server

Nslookup the Internal Lync 2010 Pool
( )

Reply with the Internal Pool IP address

Next Hop to internal Lync 2010 Pool

Nslookup from the Lync 2010 Pool

Nslookup the Lync 2010 Internal Edge interface

( )

Reply from the internal interface of the Lync Edge server

Edge Server functions

Step 2: Ports

When all DNS entries from Step 1 are valid and working, the next step to verify that all ports are open and functional. To accomplish this task perform run a series of simple Telnet tests to verify that the firewall ports are open and accepting connections. To build off the examples above, test connectivity to your Edge Servers external interfaces from any public network. The results should look like Figure 3 below. When the Telnet session connects the screen goes blank. This verifies that the port is open and properly connected.

Figure 3. C:\>Telnet FQDN Port

Table 3 is a list of all required network ports in a typical Edge Server environment. Verifying that all ports are open is a essential step when building a network architecture.

Table 3. Firewall Ports Reference Table



Telnet from External Client

Test to


Test to


Test to


Test to


Test to


Telnet from Lync 2010 Edge

Telnet to


Telnet from Lync 2010 Pool

Telnet to


Telnet to


Telnet to


Telnet to


Telnet to


Step 3: Certificates

When your DNS resolves perfectly and ports are open and communicating you are ready to address certificates.

The Lync Server 2010 Deployment Wizard facilitates the certificate setup process, but multiple issues need to be clarified to ensure a successful deployment.

Note: For assistance with setting up certificates please see the following TechNet URL: Set Up Edge Certificates .

External Interface Certificates

  • All Public facing certificates must be issued by an approved Public CA that supports Unified Communications: see Unified Communications Certificate Partners for Exchange Server and for Communications Server ... for detailed information.

  • If Public IM Connectivity (PIC) with AOL is required, the certificate must contain an Enhanced Key Usage (EKU) for the server and the client. The Lync Deployment Wizard does not request the client EKU by default. Use the following Windows PowerShell cmdlet to accomplish this task:

Request-CsCertificate -New -Type AccessEdgeExternal -Output C:\ <certfilename.txt or certfilename.csr> -ClientEku $true -Template <template name>

  • When deploying an Edge Server array, the certificate must have an exportable private key and the same certificate must be used on all Edge Servers. (A/V authentication requires this regardless of the number of servers).

  • The Certificate Name (CN) must match the FQDN of the Lync Server 2010 Access Edge external interface.

  • The Subject Alternate Names (SAN) attributes must contain the following:

    • FQDN for Access Edge (same as CN).

    • Web Conferencing FQDN.

    • All supported SIP domains beyond the primary (,

    • The A/V authentication service FQDN does not need to be listed.

    • The order of the SAN’s is not important.

  • The reverse proxy also needs a public certificate for web farm publishing. This is the FQDN configured from the internal Lync Server 2010 pool (see Figure 4).

Figure 4. FQDN

Internal Interface Certificate

  • The internal certificate can be issued by an internal PKI infrastructure or by a Public CA from the approved CA list. Utilizing an internal CA can save the expense & administrative overhead of utilizing a public entity.

  • The CN is typically the Edge Server internal interface FQDN; however a wildcard certificate is supported.

  • No SAN is required.

Reverse Proxy Certificate

  • It must be a Public CA certificate.

  • The CN is the external web farm FQDN from the Lync Server 2010 pool.

  • The SAN’s is the simple URLs configured from the Lync Server 2010 pool ( &

  • The CN must be a SAN.


Deploying an Edge Server can be the most challenging aspect of your deployment. It requires an understanding the application layer and many ancillary components such as the network layer and the Public Key Infrastructure (PKI). Because so many components must work in unison, it is easy to miss important architectural details. This document provides an easy reference for DNS, Firewall, and Certificates. We hope it will help you pinpoint issues and successfully deploy the Lync Server 2010 Edge Server.

Additional Resources


Lync Server Resources

We Want to Hear from You

Version history
Last update:
‎May 20 2019 04:18 PM
Updated by: