Any Tanjay family device (Polycom CX700, LG-Nortel 8450) currently running a Communicator Phone Edition (CPE) release (1.x or 3.5.x) cannot update directly to the Lync Phone Edition (LPE) CU6 (4.0.7577.4100) release due to a change in the way the newest firmware package was created.
For clarification the Cumulative Update for June 2012 release is commonly referred to as Cumulative Update 6 (CU6) and the previous March 2012 release was Cumulative Update 5 (CU5). Although official Microsoft documentation for Lync will not use the numeric identifiers for the various releases, throughout unofficial articles and technical forum discussions the CU nomenclature is widely used.
This can cause problems as newly purchased Tanjay devices will still ship with the older OCS firmware version because the CX700 is the only Lync Phone Edition devices supported with Office Communications Server. As there is no supported downgrade process to go from a newer Lync 4.x version down to an older OCS 3.5.x version then shipping these devices pre-installed with Lync firmware would prevent deployments still utilizing OCS from using the phones. (For an unsupported rollback procedure see Chris Lehr’s blog article.)
Instead the device will need to first be updated to any previous Lync version (4.0.7576.0 through 4.0.7577.4066) and once that is complete then it can then be upgraded to the .4100 (CU6) release successfully.
But when Microsoft releases a new cumulative update the previous version is replaced on their download site, so only the latest version is ever available for download.
Until Microsoft provides a link to download a previous version of the firmware the February 2012 (CU5) update file for the Tanjay devices can be downloaded directly from here: ucupdates_tanjay_cu5.cab
In the event that the latest update has already been approved on the Lync Server then an earlier version needs to be restored.
- Using the Lync Server Control Panel navigate to the Clients > Device Update section and highlight the line for the desired device (e.g. CX700). In the following example the .4100 version has already been approved.
- Select Restore from the Action menu to activate the previously used .4066 version.
To understand the cause of this issue the individual firmware packages can be opened to identify what has changed between previous Cumulative Updates and the most recent June 2010 release (CU6).
- Browse to the DeviceUpdateStore folder on the Front End pool file share and open any of the Tanjay family devices. The example below shows all installed firmware versions for the Polycom CX700 for English packages on Hardware Revision A devices. The available versions shown below are the RTM release (.0) the CU5 package (.4066) and the CU6 package (.4100).
- Open the 4.0.7577.4066 folder and browse down to the expanded firmware files as shown below.
- Open the CPE.bat file to view the Security Catalog information in Windows Explorer which will display details about the certificate used to sign the digital package. Then click the View Signature button on the General tab to view additional details about the digital signature.
- On the Digital Signature Details window click the View Certificate button on the General tab to show the actual digital certificate information.
- On the package Certificate window switch to the Certification Path tab, then highlight the Microsoft Root Authority object in the path and then click the View Certificate button. This will open the certificate details for the root certificate authority used to sign the certificate on this firmware package.
- On the root Certificate window switch to the Details tab, taking note that the Signature Algorithm used to sign the root certificate authority certificate is MD5 (Message-Digest Algorithm). Also note the name “Microsoft Root Authority”.
- Now return to the original folder containing the different packages and then browse down to the CPE.cat file stored in the latest 4.0.7577.4100 (CU6) package.
- Perform the exact same steps as before to locate and identify the Signature Algorithm on the root certificate authority certificate sued for the .4100 package. Notice that this package is now signed using SHA1 (Secure Hash Algorithm), and not MD5. Also note that the root CA is different
When comparing the root certificates side-by-side the unique names (Microsoft Root Authority versus Microsoft Root Certificate Authority) indicate that these packages were singed by completely different CAs using different signature algorithms and different key lengths. (Note that the validity periods on both CAs are still nowhere near the expiration dates.)
The root cause is that the newer root certificate authority certificate used to the sign the certificate issued to the firmware package has changed in the 4.0.7577.4100 (CU6) release. All Lync Phone Edition packages prior to CU6 have always used an MD5 algorithm. MD5 is an older cryptographic hash function that has long been known to be unsuitable for use in digital signatures and most current applications have migrated to at least SHA1, if not beyond to SHA2.
On the surface this should not present too much of a problem as this is not a widespread issue since all Lync Phone Edition client versions (4.x) are compatible with both MD5 or SHA1 algorithms. But the earlier Communicator Phone Edition client versions (1.x and 3.5.x) are not compatible with the newer SHA1 format.
Since all newer Aries models phones have only ever shipped with the Lync 4.x versions, then the only devices impacted by this incompatibility are the Tanjay family devices. Thus when a device running any version prior to 4.x downloads the 4.0.7577.4100 package it will not be able to validate the issuing certificate authority’s certificate and will fail to install the update in the inactive partition.
This is why the update must now be a two-step process in that any Cumulative Release prior to CU6 must be installed on the Tanjay first. And once it has a working 4.x version then the latest 4.0.7577.4100 release can be approved and successfully installed on it. It is also safe to assume that future updates (e.g. CU7) will continue to use the newer root certificate authority so this two-step process will most likely still be required.