Administration of Microsoft Lync Server 2010 : Troubleshooting (part 1)

Troubleshooting a Lync Server installation might become necessary in the event that users are unable to sign in or features seem to not work correctly. This section discusses the key components to check when issues arise. Common troubleshooting tools and tips are also provided, which should resolve many issues.

Certificates

Incorrectly issued certificates were a common issue in Office Communications Server deployments, but these issues should mostly be mitigated with the new Lync Server wizards. The option to manually request and modify the certificate still exists, which might lead to some problems.

Follow the following guidelines to rule out any certificate issues:

• Subject and subject alternative names— Ensure that the required subject name and subject alternative names have been entered for each role. The guidance for each role varies, so verify the names required when deploying a new server. Always use the certificate wizard suggested names if possible. Wildcard certificates are still technically unsupported for most scenarios.

• Key bit length— The certificate bit length must be 1024, 2048, or 4096 to be supported by Lync Server 2010.

• Template— The template used to issue the certificate should be based on the web server template. If the Lync Server 2010 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 2010. In situations where certificates are exported or copied between servers, export the private key with the certificate.

• Certificate chain— The server must be able to verify each certificate up to a Trusted Root Certification Authority. Additionally, because the server is presenting the certificate to clients, it must contain each intermediate certificate in the certificate chain.

• Certificate store— All certificates used by a 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 the clients and servers communicating with the 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, but when using an offline or nonintegrated certificate authority it might be necessary to install root certificates on clients and servers.

DNS Records

Successful operation of Lync servers is heavily dependent on correctly configuring DNS. All necessary DNS records should exist and resolve to the correct locations. Verify that all servers have a host record configured in DNS. Separate web components URLs and simple URLs are not automatically entered and must be manually created by an administrator.

Use the following sample nslookup sequence within a command prompt to check the host record of the pool:

nslookup
set type=a
lyncdirpool1.companyabc.com

A successful query returns a name and IP address. Verify that the IP returned matches the IP addresses assigned to the 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 internally, the syntax is slightly different. The following is another sample nslookup sequence:

nslookup
set type=srv
_sipinternaltls._tcp.companyabc.com

A successful query returns a priority, weight, port, and server hostname. Verify that the server name matches the pool name and the correct port is returned.

Logs

A good source of information in troubleshooting any server issue are the event logs. Lync Server 2010 creates a dedicated event log for informational activities, warnings, and errors within the standard Windows Server Event Viewer console. To view this event log, use the following steps:

Lync Server Management Shell

The Lync Server 2010 Management Shell provides several cmdlets, which are used to 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 the required Windows Firewall ports have been opened. The Test-CSComputer cmdlet must 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.

Synthetic Transactions

A new feature in Lync Server 2010 is the introduction of synthetic transactions, which are a set of PowerShell cmdlets used to simulate actions taken by servers or users in the environment. These synthetic transactions enable an administrator to conduct realistic tests against a service. In the case of a Director, the most useful synthetic transaction is the Test-CSRegistration cmdlet, which simulates a user signing in to the specified server.

The Test-CSRegistration cmdlet requires providing a target server, user credential, and SIP address. A registrar port can optionally be included. The user credential parameter’s username and password must be collected by an authentication dialog and saved to a variable as in the following command:

$Credential = Get-Credential "COMPANYABC\tom"

After the credentials are collected, the cmdlet can be run with the user credential variable previously saved.

Test-CSRegistration –TargetFQDN lyncpool1.companyabc.com –UserCredential
 $Credential –UserSipAddress "sip:tom@companyabc.com" –RegistrarPort 5061
–Verbose

Listing 1. Test-CSRegistration Example

TargetFQDN    : lyncpool1.companyabc.com
Result        : Success
Latency       : 00:00:10.9506726
Error         :
Diagnosis     :

As seen in the output, the registration test was successful.

Telnet

Telnet is a simple method of checking whether a specific TCP port is available from a client machine. From a machine that is having trouble contacting a server, use the following steps to verify connectivity to the Registrar service:

  telnet <Director pool FQDN> 5061

If the window goes blank and only a flashing cursor is seen, it means 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.