Useful Tips for Testing Your Lync Server 2010 Edge Server

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

Task	Behavior	Function
Nslookup from the External client
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 external IP of your Web Conferencing interface	Conferencing
Nslookup for AV edge (av.domain.com)	Reply with the external IP of your AV Edge interface	Audio/Visual
Nslookup for Meet Simple URL (meet.domain.name)	Reply with the external IP of your Reverse Proxy interface	Simple URL
Nslookup for Dial-In Conferencing Simple URL (dailin.domain.com)	Reply with the external IP of your Reverse Proxy interface	Simple URL
Nslookup for Lync External Web Farm (WebFarm.domain.com)	Reply with the external IP of your Reverse Proxy interface	Lync Web Services
Nslookup for Open Federation Discovery (_sipfederationtls._tcp. domain.name)	Reply with a SRV record pointing to the Access Edge interface on port 5061	Federation
Nslookup for Automatic sign-on (_sip._tls. domain.name)	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 Pool IP address	Next Hop to 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	5061/SIP
Telnet from Lync 2010 Pool
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:

FQDN for Access Edge (same as CN).
Web Conferencing FQDN.
All supported SIP domains beyond the primary (sip.contoso.com, sip.fabrikam.com).
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 (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.