Useful Tips for Testing Your Lync Server 2010

Edge Server
NextHop
7 Dec 2011 2:45 PM

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 Microsofts 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

Task

Behavior

Function

Nslookup for Access Edge

(sip.domain.com)

Reply with the

external IP
of your Access Edge
interface

IM/Presence

Nslookup your Web Conferencing Edge

(WebCon.domain.com)

Reply with the

Conferencing
external IP
of your Web
Conferencing interface

Nslookup for AV edge

Reply with the

external IP
of your AV Edge
interface

Audio/Visual

Reply with the

external IP

Simple URL

Nslookup from the External client

(av.domain.com)

Nslookup for Meet Simple URL

(meet.domain.name)

of your Reverse Proxy

interface
Nslookup for Dial-In Conferencing Simple URL
(dailin.domain.com)

Nslookup for Lync External Web Farm

(WebFarm.domain.com)

Nslookup for Open Federation Discovery

(_sipfederationtls._tcp. domain.name)

Nslookup for Automatic sign-on

(_sip._tls. domain.name)

Reply with the

Simple URL
external IP
of your Reverse Proxy
interface
Reply with the
Lync Web
external IP
Services
of your Reverse Proxy
interface
Reply with a SRV
Federation
record pointing to the
Access Edge interface
on port 5061
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
(Pool.domain.com)

Reply with the Internal Next Hop to

Pool IP address
internal Lync
2010 Pool

Nslookup from the Lync 2010 Pool

Nslookup the Lync 2010 Internal Edge interface
(LyncEdge.domain.com)

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

Task

Port/Protocol

Telnet from External Client

Test to SIP.domain.com

443/SIP

Test to SIP.domain.com

5061/SIP

Test to WebConf.domain.com

443/PSOM

Test to AV.domain.com

443/STUN

Test to WebFarm.domain.com

443/SSL

Telnet from Lync 2010 Edge

Telnet to Pool.domain.com
Telnet from Lync 2010 Pool

5061/SIP

Telnet to LyncEdge.domain.com 5061

Telnet to LyncEdge.domain.com 443
Telnet to LyncEdge.domain.com 5062
Telnet to LyncEdge.domain.com 4443
Telnet to LyncEdge.domain.com 8057
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:
o FQDN for Access Edge (same as CN).

o Web Conferencing FQDN.

o All supported SIP domains beyond the primary (sip.contoso.com, sip.fabrikam.com).
o The A/V authentication service FQDN does not need to be listed.
o The order of the SANs 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 SANs is the simple URLs configured from the Lync Server 2010 pool (meet.domain.com
& dialin.domain.com).
The CN must be a SAN.

Summary
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
DNS Resolution for Lync 2010 Edge Server
Lync Server 2010 Troubleshooting Tips

Tools
Remote Connectivity Analyzer
The OCS & Lync Sign-In Troubleshooting Tool V3.0
The Remote UC Troubleshooting Tool (RUCT)

Lync Server Resources

Lync Server 2010 Documentation Library
DrRez blog
NextHop blog
Lync Server and Communications Server resources

We Want to Hear from You

Fan us on Facebook
Follow us on Twitter
Send us e-mail

Deployment

Blog - Post Feedback Form(CAPTCHA)

Leave a Comment

Name

Comment

Post

Blog - Comment List MSDN TechNet

Comments


8 Dec 2011 4:05 PM
#

Rich

For The OCS & Lync Sign-In Troubleshooting Tool V3.0, is there a way to modify the SRV lookup to
include a '.' at end the records? (ex. _sip._tcp.domain.com.) I need this in my environment to work.

6 Feb 2012 7:54 PM

#

Sebastiaan Poels

Could you describe your problem in more detail?

A dot at the end of a record is quit normal. See also www.the.net/.../dns.php for further explanation.
The tool should work if the DNS records are created as described in the deployment guide:
technet.microsoft.com/.../gg398386.aspx

EAMatt

29 Mar 2012 9:11 PM

#

Do you have these instructions for someone that has deployed the edge server with a single edge IP
address? The ports are (Access Edge=5061, Web Conf=444, A/V Edge 443) using a single
certificate ledge.contoso.com for all services.

9 Jan 2013 3:21 PM

#

ponboquod

Good article and nice checklist!

A couple of things to consider: a ping test will be more successful than nslookup in some cases. For
instance, in topologies with a flat domain or split-brain DNS. In some of these cases, the Edge will
use the hosts file for resolution to internal addresses. Testing these with nslookup will fail or may
show an external address. A ping test will resolve the address appropriately (and may verify
connectivity depending on firewall settings).

13 Jan 2014 8:26 AM

#

Anonymous

Please help me: http://social.technet.microsoft.com/Forums/lync/en-US/38a876ae-6b3d-41ba-899d2fcdacf29bca/changing-the-internal-configuration-replication-port-for-lync-2013-edge-server?

forum=lyncdeploy


21 Jan 2014 9:34 AM
#

Harry Kochar

Very useful information :) Great Article ..

10 Sep 2014 6:05 PM

#

asdf

asdf