Troubleshooting Lync Phone Edition Issues
Excerpts:
- The key concept to understand here is that only Lync Server supports TLS-DSK certification authentication and Exchange Server does not.
- Only NTLM authentication can be used by any Lync clients to directly connect to the Exchange Client Access Server to access the account’s mailbox.
- Any device which does not currently have valid AD credentials cached (e.g. PIN Authentication was used) will not be able to successfully authenticate to an Exchange Server. Thus only devices with USB-tethering capabilities (e.g. CX600) or the ability to enter AD credentials directly on the device (e.g. CX700) will ever be able to leverage Exchange integration features.
- When the integration is functioning on the device then standard Exchange-enabled mailboxes will provide basic integration features like Calendar data, but only UM-enabled mailbox will provide Visual Voice Mail information.
- This USB-based approach to authentication offers two distinct advantages over the PIN Authentication method:
- Simpler sign-in process for users
- Exchange Integration capabilities
- It is possible although to first provision the device internally on a network where the DHCP options are configured correctly and the device can successfully download and cache a client certificate for authentication to Lync.
Common Lync Registration Issues
Below is a list of the issues which can often prevent a device from working as designed with a Lync Server deployment. This is by no means a comprehensive list, yet most of the common issues are addressed.
- Ethernet Required – This seems basic but quite often customers have attempted to use these devices as USB-only handsets and they simply will not function in this manner. The device must be connected to an Ethernet switch at minimum and receive a valid DHCP lease on the network in order to contact the Lync Server, even if USB-tethering is being used to provision the device.
- Enterprise Voice Required - The only CX device that completely functions without the user’s Telephony setting configured for Enterprise Voice is the CX100 USB. When the user account is still in the default PC-to-PC Calling mode then the CX200/CX300 USB devices will function as audio devices but the presence lights do not function. The IP-based devices (CX500/600/700/3000) will not work at all. PIN Authentication will fail, as will USB-tethering since the Lync client will never prompt for the user’s credentials. Note that actual PSTN integration is not required as it is still possible to simply set the Telephony mode to Enterprise Voice but still leave the Line URI field blank.
- Missing Automatic Configuration Records – Lync Phone Edition cannot utilize Manual Configuration and requires that Automatic Configuration records for Lync clients are properly defined in DNS. So if Windows Lync clients are manually pointed to a Lync server (either directly in the client or passed via GPO) this information is not passed to a tethered phone, the phone must perform its own automatic lookup. Thus is the proper SRV or Host (A) records are not available in the DNS server provided to the phones then they will fail to sign-in, even when tethered. If the proper SRV records are not deployed for Lync then the only other option is to use the sip.<sipdomain>, sipinternal.<sipdomain>, orsipexternal.<sipdomain> hostnames for the Lync server, pool, or Access Edge names.
- Unsupported Version – If a device ever displays a screen which simply states "The hardware version of your phone is no longer supported and is now unusable. Please contact your support team to get a replacement" then that device is essentially ‘bricked’. This only happens on pre-production hardware and in Cumulative Update 2 Microsoft no longer supported any beta devices, so if this happens contact the vendor directly to swap out the hardware in the event that a demo unit was left out in the wild somewhere after the Lync 2010 Server software was officially launched.
Common Exchange Integration Issues
- Expired Credentials – One of the most common reasons for Exchange integration issues is related to the AD credentials in the phone expiring. As previously mentioned authentication to the Lync server happens using a client certificate (TLS-DSK) but Exchange authentication happens using NTLM which requires the AD user’s credentials. If the AD user account’s password has expired then it will still be able to connect to Lync using the client certificate, but NTLM authentication to the Exchange server will fail triggering the "Microsoft Exchange integration is unavailable” error message. In this scenario the device will not prompt the user for new credentials, even when actively USB-tethered to a Lync Windows client. The current user account must manually be signed out of the device and back in to successfully update the password.
- Message Waiting Indicator – A number of devices include a Message Waiting Indicator (MWI) lamp which can be illuminated via Exchange integration (messages directly from the Exchange server) or from the Lync Server through SIP registration (via a SIP NOTIFY message). Some of the common area phone models which do not include a USB port still contain a MWI lamp (e.g. the HP 4110ip). Although these devices cannot authenticate to Exchange directly when the user has a new voice mail message the Exchange UM server will always notify the Lync server, thus the Lync client can receive the new status information from the Lync Server. One of the more common causes for this can be identified by looking for an MSExchange Unified Messaging error event of 1344 on the Exchange UM server which usually is related to a certificate configuration issue between Lync and Exchange. During TLS communications between Lync and Exchange UM the Lync server only accepts the Common Name (aka Subject Name) value of the certificate assigned to the Exchange UM service and completely ignores the Subject Alternative Field (SAN) entries. Thus if the Exchange UM service is assigned to a SAN cert which includes the server FQDN in the SAN (e.g. cas01.contoso.local) but a different FQDN in the Subject Name field (e.g.mail.contoso.com) then the MWI update message from the UM server to Lync will fail, and the client will never receive the notification. It is not until the client polls Exchange again that the new voice mail will be known about. This scenario normally translates into a longer delay for unread and read voice mail counts to refresh on any Lync client. The recommended resolution is to issue a separate certificate with only the Exchange server FQDN as the Common Name (and no SAN field) to the Exchange server and assign it to only the UM role. Alternatively a SAN certificate for all Exchange roles can still be used but the Common Name must be the server FQDN which does not always match best practices (and is not how the Exchange certificate wizard will format the certificate request by default).
- Missing Exchange Autodiscover SRV Record - This issue is a bit odd as it does not seem to be a definitive requirement. In some deployments Exchange integration has failed on all phones until the _autodiscover._tcp.contoso.com DNS Service Locator (SRV) Record was created; it appeared that the devices would simply refused to use the fall-back Host (A) record to locate the Exchange Client Access Server. Yet in other environments Exchange integration would perform normally yet the autodiscover SRV record never existed. But as it is best practice to deploy that SRV record for a properly designed Exchange autodiscover configuration then it is one of the first things to check when troubleshooting Exchange integration issues.
- Untrusted Certificates – Sometimes the Exchange Client Access servers (or load balancer) will have a certificate issued by a different Certificate Authority than what is used on the Lync servers. Often this can be a scenario where the Exchange server is using a public certificate while the Lync Front End Server has a private certificate. But since Lync Phone Edition has a shorter list of pre-installed public trusted certificates than the Windows client does then it’s possible that the device does not trust the certificate in use on Exchange. This also applies to using private internal certificates issued by a completely different certificate authority chain then was used to issue certificates to the Lync Server. Lync Phone Edition can only download the root certificate chain used on the Lync Server and is unable to download or store any additional certificates from a different CA.
- Wildcard Certificates – As previously discussed in this blog article Lync Phone Edition devices do not currently like wildcard entries in the Lync Server certificates. This carries over into Exchange integration as well, so if the Exchange certificate contains wildcard entries then the phones will also fail to establish a TLS connection with the Exchange Client Access Server thus preventing a successful authentication attempt. This issue can be identified by the error code 0x80072f06 reported in the device client log files and Mike Stacy has highlighted this issue in a past blog article as well.
Reference: http://blog.schertz.name/2012/03/troubleshooting-lync-phone-edition-issues/