One of the big improvements with the release of Office Communications Server (OCS) 2007 R2 was the new Device Update Service, much more simple than the previous version. Goodbye Windows SharePoint Services on a different server, no more additional complexity in order to update the UC devices deployed in an organization. Now, the Device Update Service is automatically installed on the Web Components Server, which is part of the Front-end server, on a consolidated topology (the only one supported in R2).
Device Update Service supports two types of UC devices: OCS 2007 R2 Communicator Phone Edition (OCPE or Tanjay) and RoundTable (must be manually configured).
Device Update Service is mostly used to upgrade OCPE phones (LG-Nortel IP8540, Polycom CX700 and older Microsoft branded), so one could expect this process to be the most common cause of troubles and frustration. And that is, in fact, the case! Now even more, since there is a new version of the firmware for OCS 2007 R2.
Before we dive into the troubleshooting process, let us know better the Device Update Service Architecture and how it works:
In the default configuration, Communicator Phone Edition connects to Device Update Service in the following manner:
The latest firmware version, (3.5.6907.0, by the time this post was written), can be downloaded from the Microsoft site. The downloaded file is a self-extracting executable that contains a .cab archive with all the supported phones.
In order to upload the update file, we must run the Device Update Service Management Console: open the OCS R2 Management Console, right click the pool and select Device Updater. From the Tools menu, click Upload .cab File, navigate to the .cab file that you want to upload, and then click Open.
Check the Pending tab of the Device Update Service Management Console to verify that the new update is listed.
You can also verify that the upload process went OK by checking the shared updates folder (if you’re using Enterprise edition). For the Standard edition, the default path is %ProgramFiles%\Microsoft Office Communicator 2007 R2\Web Components\DeviceUpdateFiles. There should be a folder hierarchy like the one depicted in the following picture. Note that there are some Logs folders that I’ll cover a little bit ahead.
After the update file is uploaded, the corresponding firmware can be approved for all devices in the organization by selecting it and then clicking Approve. The revision should be more recent than the revision for the last update the UC devices received.
Prior to making the update widely available, it is recommended that you test it on some devices. To add a test device, go to the Test Devices tab, click Add, type a Friendly Name and then fill up the MAC address or serial number of the device (there’s no need to approve the update).
Restart the device and that should trigger the update process, as described before.
If the previous version of the device is less than 1.0.522.98, it will first get updated to an interim build (1.0.522.103) that comes with OCS 2007 R2. This means that, in this case, 2 upgrade cycles are necessary before the device gets the approved/pending build.
You can use the logs in the Logs\Server\Audit\imageUpdates\ folder to audit software update requests from UC devices. There you can find some files named RequestHandlerAuditLog_<server_name>_<date>.log with the information you need to troubleshoot the update service. You can view server log files in a text editor or Microsoft Excel.
In the following example, an LG-Nortel device with version 1.0.522.34 is configured as a test device and will receive the most up-to-date firmware. Since 1.0.522.34 is lower than 1.0.522.98, the device must first be upgraded to the interim version (1.0.522.103), then reboot and finally it receives the most recent version available on the server.
Logging DateTime,User Name,User Host Address,Device Type,Request DateTime,Mac Address,Serial Number,Vendor,Model,Revision,Locale,Requested<FileName;Version;TimeStamp>[# Seperated for Multiple],Response<FileName;Version;TimeStamp>[# Seperated for Multiple]
03-06-2009 17:07:20,firstname.lastname@example.org,10.1.1.123,UCPhone,06-03-2009 09:07:20,"0021630F207B","C185H001209","LG-Nortel","IP8540","A","ENU",cpe.nbt;0.0.0.0;01-01-1601 00:00:00,
03-06-2009 17:10:39,email@example.com,10.1.1.123,UCPhone,06-03-2009 17:10:39,"0021630F207B","C185H001209","LG-Nortel","IP8540","A","ENU",cpe.nbt;0.0.0.0;01-01-1601 00:00:00,http://ocs.demo.local/DeviceUpdateFiles_Int/OCInterim/ENU/CPE.nbt;1.0.522.103;16-12-2008 04:43:58
03-06-2009 17:18:54,firstname.lastname@example.org,10.1.1.123,UCPhone,06-03-2009 17:18:53,"0021630F207B","C185H001209","LG-Nortel","IP8540","A","ENU",cpe.nbt;1.0.522.103;16-12-2008 04:43:58,http://ocs.demo.local/DeviceUpdateFiles_Int/UCPhone/LG-Nortel/IP8540/A/ENU/3.5.6907.0/CPE/CPE.nbt;3.5.6907.0;16-12-2008 04:43:58
In the first line, the device gets in-band provisioning information from the server or Enterprise pool hosting the device user account. After a *manual reboot*, on the second line, it gets the interim version. Finally, on the third line, and after an *automatic reboot* (notice the 8 minute gap) the phone receives the 3.5.6907.0 version.
But besides the logs from the update service,the IIS logs can be extremely valuable to the troubleshooting process. This is the corresponding IIS log from the example above (I removed some unnecessary lines):
#Software: Microsoft Internet Information Services 7.0
#Date: 2009-03-06 16:00:51
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken
2009-03-06 17:07:20 10.1.1.90 POST /RequestHandler/ucdevice.upx - 443 - 10.1.1.123 Microsoft+UCPhone+Device 200 0 0 124
2009-03-06 17:10:39 10.1.1.90 POST /RequestHandler/ucdevice.upx - 443 - 10.1.1.123 Microsoft+UCPhone+Device 200 0 0 171
2009-03-06 17:12:57 10.1.1.90 GET /DeviceUpdateFiles_Int/OCInterim/ENU/CPE.nbt - 80 - 10.1.1.123 Microsoft+UCPhone+Device 200 0 0 137810
2009-03-06 17:12:57 10.1.1.90 GET /DeviceUpdateFiles_Int/OCInterim/ENU/CPE.cat - 80 - 10.1.1.123 Microsoft+UCPhone+Device 200 0 0 15
2009-03-06 17:18:54 10.1.1.90 POST /RequestHandler/ucdevice.upx - 443 - 10.1.1.123 Microsoft+UCPhone+Device 200 0 0 187
2009-03-06 17:21:45 10.1.1.90 GET /DeviceUpdateFiles_Int/UCPhone/LG-Nortel/IP8540/A/ENU/3.5.6907.0/CPE/CPE.nbt - 80 - 10.1.1.123 Microsoft+UCPhone+Device 200 0 0 170679
2009-03-06 17:21:45 10.1.1.90 GET /DeviceUpdateFiles_Int/UCPhone/LG-Nortel/IP8540/A/ENU/3.5.6907.0/CPE/CPE.cat - 80 - 10.1.1.123 Microsoft+UCPhone+Device 200 0 0 15
Notice the line where the interim file CPE.nbt is downloaded to the phone. It takes some time (137.810 ms), because the file has a few megs.
2009-03-06 17:12:57 10.192.32.90 GET /DeviceUpdateFiles_Int/OCInterim/ENU/CPE.nbt - 80 - 10.1.1.123 Microsoft+UCPhone+Device 200 0 0 137810
And then, notice the line where the phone requests the most recent version available. It took 170.679 ms to download the file.
2009-03-06 17:21:45 10.192.32.90 GET /DeviceUpdateFiles_Int/UCPhone/LG-Nortel/IP8540/A/ENU/3.5.6907.0/CPE/CPE.nbt - 80 - 10.1.1.123 Microsoft+UCPhone+Device 200 0 0 170679
Now that we have a pretty good understanding of the Device Update Service, what can we do if something doesn’t go as expected? Let’s look at the troubleshooting process:
2009-03-06 12:35:36 10.1.1.90 GET /DeviceUpdateFiles_Int/UCPhone/LG-Nortel/IP8540/A/ENU/3.5.6907.0/CPE/CPE.nbt - 80 - 10.1.1.1 Microsoft+UCPhone+Device 500 19 5 62
And this pretty much covers the troubleshooting process for the OCPE devices. I would like to hear from you if you have ever encountered a distinct situation that you managed to solve in a different way.
Hi Rui, thankyou for this post, its been extremely useful.
Im sure I have followed these instructions, and also the Microsoft Deployment guides correctly, however my Polycom CX700 device isnt updating.
I can tell by the logs (imageUpdates and IIS), that it is contacting the server at bootup, and reporting the interim patch level of 1.0.522.103, however it isnt receiving the new 3.5.6907.0 version, so matter how long I leave the device.
I thought I may be able to trick it into updating, but replacing the OCInterim CPE files with the ones in the 3.5.6707.0 directory, but this didnt make any difference.
Ive ensured that the DNS A record is in place, and the user logging onto the phone has the correct rights.
Do you have any suggestions on where to go from here?
I actually just found my problem. The DeviceUpdateFiles_Int virtual directory was set to require SSL (as I believe is default in IIS7). Unticked this box and it has sorted itself out.
this is a great tutorial.
we still have some CX700 Phones with Firmware 1.0.452.0 running. We want to upgrade them now. I can login to the OCS Server (R2) now (version checking was blocking this Firmware). The device was requesting /UCDeviceUpdates/ucdevice.upx, I created that directory on the IIS 7 server and redirected it to /RequestHandler. The phone receives the ucdevice.upx file now with 0x0/200 as the last update status. Are there any other files required?
The DNS A Record ucupdates is a cname to ucupdates-r2 which is pointing to the pool FQDN.
After a manual reboot the phone is doing nothing.
Is it possible to upgrade the 1.0.452.0 firmware without a OCS R1?
Rui, awesome post. Saved me a ton of headaches.
The UCUPDATES-R2 DNS record shoud be an A record and not a CNAME.
Make sure you unblock version 1.0.452.x on the Client Filter.
I have changed the CNAME now to an A record.
The Client Filter is not blocking anything above 1.0.199.x
The phone gets the content fo the ucdevice.upx (captured via wireshark) which looks like this:
<?xml version="1.0" ?>
The device gets the following Update URL: UpdatesServerInternalUrl=https://poolname.domainname/RequestHandler/ucdevice.upx.
But the download of the cpe.nbt file never starts (I allready rebooted the device several times). Is this the correct Update URL?
Does this firmware allready understand https?
The cpe.nbt file can be downloaded anonymously.
In a previous comment, Sam solved his problem by unchecking "requires SSL" in the DeviceUpdateFiles_Int virtual dir (by default, SSL is not required).
Also make sure you're using an account that isn't signed-in elsewhere.
SSL isn´t active on DeviceUpdateFiles_Int nor on any subfolders.
Port 80 is also open.
Yes, I´m having a test account as you outlined in your tutorial, and that account is only signed in on the tanjay I want to upgrade.
Did you ever had to upgrade a phone with the firmware version bellow 1.0.522.x?
Thanks & regards edi
I can tell by the logs imageUpdates and IIS, that it is contacting the server at bootup, and reporting the interim patch level of 1.0.522.103, however it isnt receiving the new 3.5.6907.0 version, so matter how long I leave the device.
Let me start by saying that, although the title of this post refers Polycom CX700 (because was this device
I have now written a new post specific to version 1.0.452.0:
If that doeasn't solve your problem, ping me offline, using the contact form on this blog.
i'm Arwan from Indonesia, i have a problems with tanjay phone (CX 700), first : i cannot make a call from a oc client to tanjay phone but i can make it from tanjai to oc client, our mcs told me to upgrade the tanjay phone firmware, eventually IT'S WORK.. but after some minutes the tanjay phone automatically restart and upgrade it's self, after that i display of the tanjay phone cannot show up.
I try to connect it via usb port, it's detected and can connected to my oc client.. but still the same.. the tanjay phone screen still blank, but the OCS indicator of the tanjay phone work..
Anyone... please help me..
In a previous post, How to upgrade Polycom CX700 1.0.452.0 using the OCS 2007 R2 Device Update Service
I have a couple of test devices that I'm trying to update, but not having any success. I've been through this guide and comments and I think that I have everything setup correctly, but no updates even with the phones left sitting for days.
One device is running 1.0.522.71 and one is running 1.0.452. 0. Both devices show a 'Last Update Status' of 0x0/200 and both appear in the imageUpdate and IIS logs, but they aren't actually downloading the updates.
Comparing my Wireshark results to those posted by edi, I'm not getting the 'Server Version' and 'Service Version' in the response section. However, if I open ucdevice.upx in IE, 'Server Version' and 'Service Version' appear as expected.
I have been testing with the 1.0.452.0 and had the same 0x0/200 response. After some sniffing I found the problem.
The locale of the updatefiles I installed on the server (Dutch) did not match the locale of the phone (English). On the server no English update files were available. After installing the English updatefiles and aproving them in the update service everything worked. My phones are all updated to the current version.
However, after signing in the update service doesn't work anymore. When I try to change the language from English to Dutch, I get a resultcode 0x2f7d/200 (meaning "bad request").
Sniffing tells me that the phone is sending an http request unreadable URL to the correct server.
Thanks in Advance,