This article is a brief update to the process previously documented for Lync Server 2010.  In Lync Server 2013 the Device Update service is unchanged and the steps shown in that article are still applicable, so why the need for a new post on this subject?

Background

It is important to understand that although Lync Server 2013 brings a host of new 2013-branded clients (e.g. Windows, Mobility), the Lync Phone Edition (LPE) client was not updated in the same manner.  Microsoft continues to release semi-quarterly Cumulative Updates of firmware for the various LPE models.  In the round of releases in December 2012 and January 2013 (aka CU7) official support for Lync Server 2013 was added, as well dropping the ‘2010’ from the previous name of Lync 2010 Phone Edition.  This signals the intent to provide a single LPE client for both Lync platforms and not have separate 2010 or 2013 clients with different interfaces.

What this all means is that to utilize any Lync Phone Edition devices with Lync Server 2013 the phone firmware may need updated to at least the CU7 release, which is version 4.0.7577.4363 / .4366 / .4372 for different device families.  As of the writing of this article the most recent firmware release is from April 2013 (CU8 or 4.0.7577.4387).

Understand that although Microsoft officially supports Lync Phone Edition with Lync Server 2013 starting with this CU7 release it is often still possible to register directly to Lync Server 2013 environments with many older firmware versions.  In these cases it will still be required to update Tanjay device in a two-step process to get to a supported version.

The oldest tested version which could successfully register to a Lync 2013 server is 3.5.6907.187.  Attempts to use 1.0.522.x versions would always fail with SIP 401 Unauthorized errors regardless of the client version policy configuration.

As older versions of firmware may still be in use or come pre-installed on new devices then there may exist a scenario where the devices are unable to successfully sign-in to a Lync Server 2013 environment (specifically OCS 2007 RTM versions).  And because the only way to update the Lync Phone Edition firmware is by the device requesting and downloading the package from the Lync Server then this appears to be a cyclic problem.  How can a device which cannot register to the server download an update from the server when it needs to first register to be provided the device update server information?  This might mean that the device would instead need to be connected to and registered to Lync 2010 server first, then updated to CU7 or higher, no?

Actually, no.  There is one alternative which would allow any previous version of Lync Phone Edition to download an update package directly from a Lync 2013 server without even the ability to first successfully register to it.

This little-known behavior is hardcoded into all firmware releases.  The phones are programmed to look for a specific hostname which is not typically included in the Lync topology, but if it is added manually to the environment then phones will be able to update without signing in.  Normally device updates are triggered after signing in to the Lync Server as described in detail in the previous article.

But by adding the suggested configuration to a Lync 2013 server as outlined in this article then the issue can be avoided and devices can be updated as needed.

Behavior

When a Lync Phone Edition device is powered up and receives a successful DHCP lease it will look for the commonly used DHCP Option 15 parameter which provides a single DNS Domain Name.  It will also query for the optional DHCP Option 119 which provides a DNS Search List.  In an environment that contains multiple domain names then Option 119 can be leveraged to provide more than one domain name to the client.

The device will then automatically perform a DNS query for the hostname ucupdates-r2.<domainname> for each domain name which may have been passed via those DHCP options.

Typically the certificate issued to the Lync Front End server is from an internal private Certificate Authority, which unfortunately means the device cannot automatically download the update without intervention.  Lync Phone Edition will only attempt to retrieve the root certificate from the internal, Active Directory published CA during registration attempts, it was not programmed to perform this same action automatically upon bootup.

So in this case user-intervention is required by attempting to sign-in to the Lync Server.  The registration does not need to actually succeed so if the phone is running a vey old version incapable of registering to the Lync server for some reason, or an invalid PIN is used simply to speed up the process it does not matter.  Simply initiating the registration process is sufficient to trigger the root certificate retrieval process via DHCP Option 43.

In the event that a trusted public certificate is used this is not an issue, but this is a rare to impossible scenario as discussed in this blog article.  A public Certificate Authority will no longer issue certificates which include names which are not valid FQDNs, so requests containing short hostnames and internal namespace utilizing an invalid Top Level Domain (TLD) like .local will be denied.  Due to these factors it is realistically not possible to use a public certificate on the internal Lync server and support LPE upgrades prior to successful registration as covered in this article.  An AD-integrated Enterprise CA must be used to issue the certificate to the Lync Server.

Requirements

The Device Out of Box section shown at the bottom of this page in TechNet lists the requirements to support this registration-less device process.

• The phone must be on the corporate network.  This statement defines that the process will only work on devices connected internally which have direct access to the Lync Front End server.  This process is not supported for devices connecting outside of the Edge Server and Reverse Proxy server.
• The UCUpdates-R2 host record must be created in DNS.  Clearly the phone will need to correctly resolve the hardcoded DNS entry so a Host record needs to be defined in DNS.  Only the FQDN needs to be defined, there is no need to deploy a WINS server solely for shortname resolution as the device only needs to resolve the FQDN. The example below (ucupdates-r2.schertz.name) shows that the Active Directory domain namespace, and not the SIP domain namespace is utilized in the event that these are not the same namespace.  The phone will utilize the AD domain presented in DHCP (covered in a later step) to located the update FQDN, not the SIP domain.

• Device Update certificate must have SAN entries containing the hostname and FQDN.  This means that the certificate installed on the Lync Front End server and assigned to the internal web services usage at a minimum which the device will connect to for the device updates must have both a Fully Qualified Domain Name entry (e.g. ucupdates-r2.schertz.name) as well as a short hostname (ucupdates-r2) defined in the Subject Alternative Name field.  By default the Lync Certificate Wizard does not include either of these as options so typically they are not already defined.  But a new certificate request can be generated with these entries added to the request manually in the wizard.  The short hostname must be included in the certificate even though the device does not need to actually resolve this shortname (WINS is not a requirement for this solution).  During the update process the phone will actually use the hardcoded shortname to connect to the Lync server even though the FQDN is used to resolve the server’s address.  If the shortname is missing from the certificate then a TLS connection will fail to be established, preventing the device from accessing the update web service.

• Network Time Protocol (NTP) must be configured correctly for the device.  Without an available time source the device will not be able to connect to and communicate with the Lync Server.  If neither a Network Time Service Locator Record (SRV) nor DHCP Option 42 is available on the network then LPE will fall back to connecting to the hard-coded time.windows.com host to locate a time source.
• DHCP Options 15, 43, and 120 must be defined.  The 43 and 120 options utilized by the PIN Authentication process need to be present in order to download the root certificate from the internal CA, as described in this previous article.  Also make sure that Option 15 is configured to provide the AD domain name (e.g. schertz.name) so that the phone knows what domain namespace to search for the ucupdates-r2 FQDN in.

.

Update Process

• Connect a phone to the network which is currently installed with a firmware version older than what is approved on the Lync Server.
• Perform a soft-reset on the phone to wipe any cached client credentials or certificates.

The following text is from a network capture run on the DNS server which shows the device asking for the IP address of the ucupdates-r2<domainname> query for the only domain name provided by the DHCP Option 15 value.

DNS:QueryId = 0x3, QUERY (Standard query), Query  for ucupdates-r2.schertz.name of type Host Addr on class Internet    {DNS:517, UDP:516, IPv4:513}

A network capture run on the Lync server will show the following traffic indicating that the phone has requested to establish a TLS session with the Lync Server, which then passes its server certificate to the phone in the following message. 

TLS:TLS Rec Layer-1 HandShake: Server Hello. Certificate. Server Hello Done.    {TLS:43, SSLVersionSelector:41, TCP:40, IPv4:39}

Understand that this is the Lync server handing its assigned server certificate to the client, this is not the root CA certificate, so shown below by the certificate’s common name appearing in the trace data.

Traffic from the phone to the Lync server at this point will stop for a period of time as the connection cannot be established. Check the System Information menu on the phone to validate this failure by verifying that the Last Update Status code is reported as 0x2F0D/0 which resolves to the error message of ERROR_WINHTTP_SECURE_INVALID_CA as covered in this troubleshooting article.  This confirms that the device does not inherently trust the certificate assigned to the Lync server so the root CA certificate which signed the Lync server certificate must be downloaded to the phone.

• To resolve this issue attempt to sign-in on the device using PIN Authentication to trigger a download of the root CA certificate.  Simply enter a bogus phone number and let the process fail.

A network trace running on the Lync server will show the server response to the device request to retrieve the root certificate chain during the sign-in attempt.

SOAP    SOAP:xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"    {HTTP:13, TCP:12, IPv4:39}

That SOAP response contains the public key of the root CA certificate as shown below.

<GetRootCertChainsResponse ResponseClass="Success" xmlns="http://schemas.microsoft.com/OCS/AuthWebServices/">
<RootCertChains>
  <Chain>
   MIIDmgYJKoZIhvcNAQcCoIIDizCCA4DALBgkqxFzAVBgoJkiaJk/IsZAEZFzY2hlcn…<snipped>
  </Chain>
</RootCertChains>
</GetRootCertChainsResponse>

At this point the device should now have the required root certicate in its store to support TLS communications with the Lync Server.  All that is left now is to return the phone to main menu and leave it ide to do its thing.

It is important to not leave the phone at the failed Desk Phone Setup screen pictured above otherwise the update process will not begin.

• Select Backspace and then Back enough times to return to the initial Welcome screen and then leave the device alone.  Seriously, don’t touch it.

The automatic device update process should kick-off within a few minutes, but there will be no indication on the device that this is happening.  To validate that anything is actually happening then leverage the Lync server logs and fight the urge to check the phone’s menu, as any activity on the phone will reset the idle timer back to zero and just delay the pending update process.

• To confirm that the device has queried the server for any approved updates check the latest RequestHandlerAuditLog file located by default in the DeviceUpdateLogs folder.

\\LyncShare\1-WebServices-1\DeviceUpdateLogs\Server\Audit\imageUpdates
RequestHandlerAuditLog_lync_05312013.log

• Open the file and look for the most recent log entry and verify that the IP address matches the test device and that path to the image file (CPE.nbt) is passed to the device.

05/31/2013 17:08:10,,192.168.1.104,UCPhone
5/31/2013 3:08:07 PM,"0004F29531A2","0004f29531a2","POLYCOM","CX600","Rev-4","ENU",cpe.nbt; 4.0.7577.4366;12/18/2012 5:56:16 PM, http://lync.schertz.name/RequestHandler/Files/UCPhone/POLYCOM/CX600/
Rev-4/ENU/4.0.7577.4387/CPE/CPE.nbt; https://lyncweb.mslync.net/RequestHandlerExt/Files/UCPhone/POLYCOM/CX600/
Rev4/ENU/4.0.7577.4387/CPE/CPE.nbt;
4.0.7577.4387;4/10/2013 6:55:12 AM

Note that the first firmware version listed is what is currently on the device (.4366) while the later instances reflect the currently approved version (.4387) for this specific device model.  The HTTP URL highlighted in red is the internal URL that the device will utilize to download the firmware package.  (The second HTTPS URL is for externally registered devices which is not applicable for the purposes of this article.)

After a few additional minutes of idle time the phone will automatically reboot, activating the newly downloaded firmware version.