Updating Lync Phone Edition Devices
By default an installation of Lync Server does not contain any pre-installed or pre-approved updates, this must be performed manually by an administrator. This is basically the same process as was used in Office Communications Server except that now there are multiple update packages, which on the surface appear to be identical. Previously the only supported devices that used the Office Communicator Phone Edition client were the Microsoft reference-design “Tanjay” family of devices: the Polycom CX700 and LG-Nortel IP8540. Both phones were identical and used the exact same software so a single installation package was distributed and updated on a regular basis.
Lync Server 2010 now has multiple versions of the update package, as they are both different clients (with different interfaces and features) as well as different device designs between vendors. The Lync Phone Edition client now has two different interfaces. First, the original touchscreen-based client which started in OCS on the CX700 and was updated for Lync. This client looks nearly identical to the previous version but has a few tweaks (most prominently a Lync Server branded background). Secondly there is a brand new Lync Phone Edition client which only runs on the new Aries family devices: the Polycom CX500, CX600, CX3000 and Aastra 6721ip, 6725ip. Although the client features are identical between the Aries devices the firmware is unique between the different manufacturer’s devices in order to support differing hardware components and physical features. So there are now three separate packages which can be downloaded: one for the original Tanjay devices, a second for Polycom’s Aries devices, and a third for Aastra’s Aries devices. These packages unfortunately are all identically named as ucupdates.exe so be careful when downloading more than one at a time.
Additionally Microsoft plans to release new versions of the Lync Phone Edition client quarterly as Cumulative Updates (CU). Just last week CU1 was released and CU2 is slated for release in Q2 2011. These are not service pack type updates but are instead the full client repackaged as a single firmware. Previous releases for the same device family and edition are then taken offline so that only the latest edition is typically available at any given time (previous URLs will be forwarded to the latest editions as well).
The latest firmware packages can be found in the article Updating Lync 2013 under the Lync Phone Edition table, which was previously included in this article but has since been moved into the newer article which documents the past of various client and server updates.
If the Lync Server environment is prepared correctly to support standard operation of the devices (detailed in this previous article) then the following process can be used to prepare, test, and update devices.
When working with Tanjay devices the Lync Server Client Version Policy by default blocks OCPhone clients running version 1.0.196 or older. These are very old beta versions that I have not even had my hands on in a long time and unfortunately cannot test upgrading them directly against Lync Server. My advice is to upgrade these using an OCS environment with this process documented by Rui Silva. If a device has the slightly newer beta version 1.0.452 or 1.0.522 then this process also documented by Rui can be used. In most cases the latest OCS 2007 R2 software (3.5.6907) will be installed on a Tanjay and this version is capable of signing directly into Lync Server given that the required DHCP options are configured.
- An important caveat to discuss is that the older OCS 2007 and 2007 R2 clients are programmed to look for ucupdate and ucupdates-r2 hostname, respectively. This calls for additional DNS records and certificate SAN entries to be included in the Lync deployment. This is quite undesirable as most often by the time an administrator reaches this portion of the deployment the certificates have already been requested and installed. Well, the Updating Devices portion of the Lync Server TechNet documentation covers this but does not explain that it is not necessary. As long as a Lync Server supported client version is already installed on the Tanjay device then by simply signing into the phone using a Lync user the phone will be able to connect to the Device Update Service using the Lync server/pool FQDN passed down to it. Thus there is no need to use those other hostnames in the environment. I have updated out-of-the-box Tanjay devices to the Lync RTM edition with no additional configuration in basic Lync Server environments with none of the ucupdates hostnames configured.
- When updating Aries device there are no legacy hostnames used and as these devices only operate with Lync Server. The process is even simpler to support, except for the case that a pre-release beta device is in question. The large majority of Aries devices in existence today will have at least the Release Candidate version (4.0.7457), if not already at RTM.
1. Select a device and identify the current version.
2. Download and install the update package on to the Lync Server.
3. Configure a test device to first validate a successful update and working installation.
4. Trigger an update on the test device (or just wait).
5. Review multiple log files on the Lync Server.
6. Approve the update for all devices.
Selected for this process is a factory-fresh Polycom CX500 Rev-C device, pre-installed with the Lync Release Candidate 7457 build.
- Connect the phone to the network and sign-in using a SIP-enabled, Enterprise Voice-enabled user account on the Lync Server pool. (As the CX500 is an Ethernet only device PIN Authentication is used, but a USB-enabled device like the CX600 can be tethered to a laptop to sign-in as well).
- Complete the device customization wizard if prompt, or just skip it if not concerned with setting time zone or ring tone settings at this point.
- Once at the home screen press the Menu button and select System information to view the Version number of the currently installed firmware. The Release Candidate 7457 build is indicated by the following screenshot.
Install Update Package
Using the links provided in the table in the beginning of this article download the appropriate package(s) and save it on the Lync Server.
- Download the latest ucupdates.exe package for Microsoft Lync 2010 Phone Edition for Polycom CX500, Polycom CX600 and Polycom CX3000.
- Execute the downloaded program and select a directory to expand the ucupdates.cab file to.
The next step is to import the expanded CAB file into Lync Server using the command shell, as this process cannot be performed from the Control Panel.
- From the Lync Server Management Shell execute the following cmdlet to import the update cab file into Lync Server. The -Identity value format is important and must be exactly service:WebServer:<LyncFQDN> while the –FileName value is simply an absolute path to the extracted CAB file.
Import-CsDeviceUpdate -Identity service:WebServer:lync.schertz.local -FileName C:\temp\UCUpdates.cab
It may take a few seconds for the cmdlet to complete but once it does open the Lync Server Control Panel (LSCP) and go to Clients > Device Update and the new version should be displayed as Pending Version on the appropriate devices.
The import can also be verified by locating the installed files on the Lync Server which are stored in the Lync File Share path.
Configure Test Device
As with all software updates it would be prudent to first test one a single device before blasting it out to all of the phones in the organization. The Test Device configuration in Lync Server allows for a single device to automatically download the latest version of the software available regardless of whether it has been approved yet or not.
- From the LSCP navigate to Clients > Test Device and select New > Global Test Device. Enter anything for the Name (e.g. Test CX500) and select the MAC address Identifier Type. For the Unique Identifier enter the MAC address of the phone with no separator characters. The MAC is most easily viewable directly from the device on the System Information menu pulled up in Step 1 of this process.
4. Trigger Update
At this point a reboot of the phone can help kick things off a bit quicker as well as make it easy to track the progress though server logs which may be full of activity from other devices in use on the network. But understand this is not necessary and now that the Test Device is created the associated device will update on it’s own after a period of inactivity (typically 10 minutes). The reboot simply triggers the phone to look for an update without waiting as long.
- Make a note of the current time and reboot the device. It will automatically sign-in with the current user account and immediately lock. This starts the inactivity timer.
- Now, do nothing. Seriously, just leave the phone alone. Don’t unlock it or push any buttons. Don’t even look at it. In fact, go to lunch.
Review Server Logs
While waiting the IIS server logs on the Lync Server can be viewed to see what the phone is up to, as well as keep an eye out for the update version check. There are two different logs which will contain device request details, the IIS logs and the Lync Device Update logs.
- In the default inetpub directory locate the most recent W3SVC log file and scroll to the end of the file to view the latest activity. (Here is a tip: close the LSCP when working with the IIS logs as it will create a large amount of “POST /Cscp” entries which must be wade-through to find the device connection entries.)
- When the phone signs-in to Lync Server a number of log entries will appear from the IP address of the device showing the login process utilizing web tickets and a Location Information Service (LIS) data. The current firmware version (4.0.7457) can be seen in the client requests.
2011-01-23 17:39:21 192.168.103.23 POST /RequestHandler/ucdevice.upx – 443 – 192.168.103.105 Microsoft+UCPhone+Device+(lcs_se_w14_main:824457:2010/10/21:23:13:00) 200 0 0 42
2011-01-23 17:39:21 192.168.103.23 POST /WebTicket/WebTicketService.svc/cert – 443 – 192.168.103.105 OCPhone/4.0.7457.0+(Microsoft+Lync+2010+Phone+Edition) 200 0 0 36
2011-01-23 17:39:21 192.168.103.23 POST /RequestHandler/ucdevice.upx – 443 – 192.168.103.105 Microsoft+UCPhone+Device+(lcs_se_w14_main:824457:2010/10/21:23:13:00) 200 0 0 160
2011-01-23 17:39:21 192.168.103.23 POST /locationinformation/liservice.svc/WebTicket_Bearer – 443 – 192.168.103.105 OCPhone/4.0.7457.0+(Microsoft+Lync+2010+Phone+Edition) 200 0 0 130
- Immediately after the device will perform two HTTP GET requests for the NBT and CAT files of the latest firmware version allowed for its device type. Because the MAC address for this device matches the Test Device created earlier the Device Update server passes files for version 4.0.7577.107 to the device request.
2011-01-23 17:40:26 192.168.103.23 GET /RequestHandler/Files/UCPhone/POLYCOM/CX500/Rev-4/ENU/4.0.7577.107/CPE/CPE.nbt – 80 – 192.168.103.105 Microsoft+UCPhone+Device+(lcs_se_w14_main:824457:2010/10/21:23:13:00) 200 0 0 63991
2011-01-23 17:40:26 192.168.103.23 GET /RequestHandler/Files/UCPhone/POLYCOM/CX500/Rev-4/ENU/4.0.7577.107/CPE/CPE.cat – 80 – 192.168.103.105 Microsoft+UCPhone+Device+(lcs_se_w14_main:824457:2010/10/21:23:13:00) 200 0 0 17
- Once the device completes downloading and installing the new firmware it waits for additional inactivity time before rebooting. This allows the updates process to run in the background, yet the device will not reboot while it’s in use. since the device in this example has been locked throughout the process happens pretty fast. In this log it was 7 minutes later when the device rebooted and the web ticket request now shows the updated version number.
2011-01-23 17:47:16 192.168.103.23 POST /CertProv/CertProvisioningService.svc/mex – 80 – 192.168.103.105 OCPhone/4.0.7577.107+(Microsoft+Lync+2010+Phone+Edition) 200 0 0 9
Okay, now the phone can be used. Go ahead. Unlock it and check the System Information menu to see the new version number reported.
The Device Update Update server logs can also be used, which show even more detail. But unless a device ‘checks-in’ for an update nothing will appear in these logs so starting with the IIS logs is a good troubleshooting habit.
- Browse to the Lync Server’s DeviceUpdateLogs directory which is stored in the Lync File Share and open the RequestHandlerAuditLog_lync_xxxxxxxx.log for the current day.
Within the log two distinct entries should be seen for the specific CX500 device which was updated. The first line shows the device on it’s original 7457 build asking for the internal and external URLs to download an approved update from. Also note that the device’s specific hardware revision (Rev-4) is listed in the request. This information is later used to select which packages should be approved for updates in the specific environment.
01/23/2011 11:39:21,email@example.com,192.168.103.105,UCPhone,1/23/2011 11:39:18 AM,"0004F2953DFC","0004f2953dfc","POLYCOM","CX500","Rev-4","ENU",cpe.nbt;
4.0.7457.0;12/24/2010 8:11:02 AM,
https://<externalFQDN>.mslync.net/RequestHandlerExt/Files/UCPhone/POLYCOM/CX500/Rev-4/ENU/4.0.7576.0/CPE/CPE.nbt;4.0.7576.0;10/22/2010 3:15:24 AM
Less than 10 minutes later a second entry from the same device appears, this time reporting that it is running the latest 7577 build. The device is again asking for a download package, but since it is now on the latest approved no URL response is given by the Lync Server.
01/23/2011 11:47:19,firstname.lastname@example.org,192.168.103.105,UCPhone,1/23/2011 11:47:18 AM,"0004F2953DFC","0004f2953dfc","POLYCOM","CX500","Rev-4","ENU",cpe.nbt;
4.0.7577.107;1/11/2011 3:33:08 PM,
After some time has passed and sufficient testing has been completed in the environment then each of the supported device updates should be approved so any device can be updated automatically. The Test Device object can be retained for later use or deleted if no longer testing with that specific device.
- From the Lync Server Control Panel navigate to Clients > Device Updates, highlight the desired devices and select the Approve action.
As my test environment contains Polycom production Aries devices then only the Rev-4 package was selected for approval. Notice that the previously approved 7576 version is now configured as the Restore Version. Additionally the latest Tanjay package has not yet been installed, but the previous RTM version of 7576 is already approved.