Troubleshooting Edge Servers is necessary in the
event that users are unable to sign in or some features become
unavailable. This section discusses the key components of an Edge Server
to check when issues arise. Common troubleshooting tools and tips are
also provided, which should resolve many issues.
Firewall Ports
Connectivity to an Edge
Server or reverse proxy can be limited by firewalls and tricky to
troubleshoot because the connections generally cross a few network
boundaries.
Routing
Any time a server has
multiple network adapters, it can be problematic to make routing work
correctly. Ensure that requests destined for the internal network are
routed out the correct network adapter by using tools such as packet
sniffers or traceroute. Packet capture tools have the capability to
monitor a specific adapter, so it should be easy to determine whether
traffic is flowing through an adapter.
Certificates
Incorrectly issued certificates are a potential issue with Edge Server configuration.
Tip
As
a best practice, always use the built-in Certificate Wizards because
they automatically generate the correct names for a server role. Only
the Access Edge and Web Conferencing Edge certificates need to be issued
by a public certificate authority. The internal Edge certificate and
A/V Authentication certificates are used only by internal clients.
Follow the guidelines to rule out certificate issues.
- Key Bit Length—The certificate bit length must be 1024, 2048, or 4096 to be supported by Lync Server.
- Template—The
template used to issue the certificate should be based on the web
server template. If the Lync Server Certificate Wizard is used, the
correct template will automatically be applied.
- Private Key—The
server certificate must have the private key associated to be used by
Lync Server. In situations where certificates are exported or copied
between servers, export the private key with the certificate.
- Certificate Chain—The
Edge Server must be able to verify each certificate up to a Trusted
Root Certification Authority. Additionally, because the server presents
the certificate to clients, it must contain each intermediate
certificate in the certificate chain.
- Certificate Store—All
certificates used by the Edge Server must be located in the Personal
section of the local computer certificate store. A common mistake is to
place certificates in the Personal section of the user account
certificate store.
- Certificate Trust—Be
sure that the clients and servers communicating with the Edge Server
all contain a copy of the top-level certificate authority of the chain
in their Trusted Root Certification Authority local computer store. When
the certification authority is integrated with Active Directory, this
is generally not an issue. When using an offline or nonintegrated
certificate authority, install root certificates on clients and servers.
Additionally, each service has slightly different requirements for the subject and subject alternative names.
Edge Internal Certificate Names
The required name for an Access Edge Server certificate is as follows:
Access Edge Certificate Names
The required names for an Access Edge Server certificate are as follows:
Subject Name— Ensure that the subject name matches the Access Edge FQDN entered in the Topology Builder.
Subject Alternative Names— The SAN field must contain all supported SIP domains in the sip.<SIP Domain> format.
Web Conferencing Edge Certificate Names
The required name for a Web Conferencing Edge Server certificate is as follows:
A/V Authentication Certificate Names
The media relay certificate doesn’t have any specific name requirements, but as a best practice use the following:
Wildcard Certificates
Some organizations attempt to use
wildcard certificates or a single certificate with subject alternative
names that attempt to cover all possible names. There are certainly some
cases where this configuration might work, but in the end the
simplicity of following the actual name requirements tends to outweigh
any small cost savings achieved by using fewer certificates. If
attempting one of these configurations and experiencing issues, use the
correct names to see whether it resolves the issue.
DNS Records
Successful sign-in to an Edge Server is heavily dependent on correctly configuring the DNS.
Tip
It is important to check that all necessary DNS records exist and resolve to the correct locations.
The following sample NSLookup sequence within a command prompt checks the host record of the pool:
nslookup
set type=a
lyncedgepool1.companyabc.com
A
successful query returns a name and IP address. Verify that IP returned
matches the IP addresses assigned to the Edge Servers or load balancer
and that no extra, or surprise, IP addresses are returned.
To verify the SRV record
required for automatic client sign-in externally the syntax is slightly
different. The following is another sample NSLookup sequence:
nslookup
set type=srv
_sip._tls.companyabc.com
A successful query
returns a priority, weight, port, and server hostname. Verify that the
server name matches the Edge pool Access Edge FQDN and the correct port
is returned.
Use the same steps to verify that the following services resolve correctly in public DNS:
For internal DNS, verify that clients can resolve the following:
Tip
Verify that the Edge
Server can verify internal DNS names. It must be able to resolve the
names of internal Lync Server servers to send and receive messages.
Logs
A good source of information
when troubleshooting any server issue is the event logs. Lync Server
creates a dedicated event log for informational activities, warnings,
and errors within the standard Windows Server Event Viewer console. To
view this event log, perform the following steps:
1. | Click Start.
|
2. | Type eventvwr.msc and click Enter to open the Event Viewer Microsoft Management Console.
|
3. | Expand the Applications and Services Logs folder.
|
4. | Click the Lync Server log.
|
5. | Examine the log for warning or error events, which might provide additional insight into issues.
|
Lync Server Management Shell
The Lync Server
Management Shell provides several cmdlets, which test various functions
of a server. A useful cmdlet for verifying the overall health of a
server is Test-CSComputer server, which verifies that all services are
running, the local computer group membership is correctly populated with
the necessary Lync Server Active Directory groups, and that the
required Windows Firewall ports are open.
The Test-CSComputer cmdlet must be run from the local computer and uses the following syntax:
Test-CSComputer –Report "C:\Test-CSComputer Results.xml"
After running the cmdlet, open the generated XML file to view a detailed analysis of each check.
Telnet
Telnet is a simple method of
checking whether a specific TCP port is available from a client machine.
From a machine that has trouble contacting an Edge Server, use the
following steps to verify connectivity to the Access Edge or Web
Conferencing services:
Tip
The Telnet client is not
installed by default in Windows Vista, Windows 7, Windows Server 2008,
or Windows Server 2008 R2. On a desktop operating system, it must be
installed by using the Turn Windows Features on or off option found in
Programs and Features. On a server operating system, it can be installed
through the Features section of Server Manager.
1. | Open a command prompt.
|
2. | Type the following command:
telnet <Access Edge FQDN> <443 or 5061>
|
If the window goes blank
leaving a flashing cursor, the connection was successful and the port
can be contacted without issue. If the connection fails, an error is
returned. Check that the services are running on the Director and that
no firewalls are blocking the traffic.
Services
Basic troubleshooting
begins with making sure the Lync Server services are all running. When
services are in a stopped state, users will notice many issues such as
being unable to sign in or connect to the Edge Server. Verify that the
following services are configured to start automatically and are
running.
Lync Server Access Edge
Lync Server Audio/Video Authentication
Lync Server Audio/Video Edge
Lync Server Replica Replicator Agent
Lync Server Web Conferencing Edge
