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.
1. Firewall Ports
Connectivity to an Edge Server or
reverse proxy can be limited by firewalls and can be tricky to
troubleshoot because the connections generally cross a few network
boundaries.
2. Routing
Anytime 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. It is important to make sure you have
properly configured Windows persistent routes. Use the ROUTE PRINT command to verify routes on each of your Edge Servers.
3. Certificates
Incorrectly issued certificates are a
potential issue with Edge Server configuration. It is common for
Intermediate and Root Certificates to be missing from Edge Server
Deployments. This will cause intermittent, or even complete, failures
on most connections to the Edge Server. Confirm that you have all
required certificates installed from your public Certificate Authority.
DigiCert offers a free certificate-checking utility online that can
verify the proper installation of certificates. This tool can be found
at http://www.digicert.com/help.
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 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 is automatically applied.
• Private Key—The
server certificate must have the private key associated to be used by
Lync Server. In situations in which 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 generally is 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.
4. Edge Internal Certificate Names
The required name for the Internal Edge certificate is as detailed here:
• Subject Name—Ensure that the subject name matches the internal Edge pool FQDN entered in the Topology Builder.
• Shared Certificate—Remember
that in a Load-Balanced Edge Server Pool, all servers in that pool must
share the same internal certificate with the same private key.
