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








































































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.


Additional Resources



Tools



Lync Server Resources



We Want to Hear from You


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