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
|
Reply with the external IP
|
IM/Presence |
|
Nslookup
your Web Conferencing Edge
|
Reply with the external IP
|
Conferencing |
|
Nslookup for AV edge ( av.domain.com ) |
Reply with the external IP
|
Audio/Visual |
|
Nslookup for Meet Simple URL ( meet.domain.name ) |
Reply with the external IP
|
Simple URL |
|
Nslookup for Dial-In Conferencing Simple URL ( dailin.domain.com ) |
Reply with the external IP
|
Simple URL |
|
Nslookup for Lync External Web Farm ( WebFarm.domain.com ) |
Reply with the external IP
|
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
|
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
- 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