the UC Guys

Communicator Phone Edition Device Updates Failing from External Network Location

The new Communicator Phone Edition (CPE) Device Update Service in Office Communications Server (OCS) 2007 R2 is 1000 times better than in the previous release where you had to set Windows Sharepoint Services (WSS) 3.0 and stand on one leg and pray you had everything configured perfectly. I'm not sad one bit to see that mess go J

In OCS R2, WSS is gone and the Device Updater is built right into the Front-End Server. An intuitive interface allows you to upload and manage the device updates with ease.

I did run into one issue, and now confirmed a bug by Microsoft PSS, whereby R1 CPE devices would not update when connected externally to a network. In this case 100% of the users were external to the OCS network that was hosted at a data center so the phones are in various home and client offices. The phones would show a "0x0/401" status in the about menu. Upon further investigation this error code suggested that an unauthorized user was attempting to connect. Seemed strange since you could log on with the user account and the phone worked as it should. It just wouldn't update get the update. In the IIS 7 logs you would see the same error when the phone did a post for /RequestHandlerExt/ucdevice.upx. Notice the 401 after the Microsoft+UCPhone+Device entry below..

2009-08-13 13:28:39 192.168.1.43 POST /RequestHandlerExt/ucdevice.upx - 443 - 216.221.86.228 Microsoft+UCPhone+Device 401 2 5 12

2009-08-13 13:28:47 192.168.1.43 POST /RequestHandlerExt/ucdevice.upx - 443 - 216.221.86.228 Microsoft+UCPhone+Device 401 2 5 12

2009-08-13 13:37:44 192.168.1.43 POST /RequestHandlerExt/ucdevice.upx - 443 - 216.221.86.228 Microsoft+UCPhone+Device 401 2 5 14

 

After confirming everything was confirmed to be setup correctly and pulling out the last of my remaining hair, I opened a PSS Case and explained the issue to the engineer. He quickly identified the issue as an undocumented bug and asked me to make a couple of changes.

First, we added Anonymous Logon to the RequestHandlerExt virtual directory NTFS permissions:

Secondly, we changed the RequestHandlerExt Authentication options by enabling Anonymous Logon:

 

After restarting IIS 7 and rebooting the Polycom CX700, the phone was able to download the new update. The phone showed and update status of 0x0/200 and you could also see this in IIS 7.0 as shown here:

2009-08-13 13:43:47 192.168.1.43 POST /RequestHandlerExt/ucdevice.upx - 443 - 216.221.86.228 Microsoft+UCPhone+Device 200 0 0 3683

2009-08-13 13:47:28 192.168.1.43 GET /DeviceUpdateFiles_Ext/UCPhone/Polycom/CX700/A/ENU/3.5.6907.35/CPE/CPE.nbt - 443 - 216.221.86.228 Microsoft+UCPhone+Device 200 0 0 220879

2009-08-13 13:47:28 192.168.1.43 GET /DeviceUpdateFiles_Ext/UCPhone/Polycom/CX700/A/ENU/3.5.6907.35/CPE/CPE.cat - 443 - 216.221.86.228 Microsoft+UCPhone+Device 200 0 0 164

2009-08-13 13:58:15 192.168.1.43 POST /RequestHandlerExt/ucdevice.upx - 443 - 216.221.86.228 Microsoft+UCPhone+Device 200 0 0 181

 

You can also verify this in the Request Handler Audit Log located on your front end server (C:\Program Files\Microsoft Office Communications Server 2007 R2\Web Components\DeviceUpdateFiles\Logs\Server\Audit\imageUpdates)

 

You should see an entry for every phone connecting, the current firmware it is on and whether it has made a request to download the new firmware. The first entry shows a phone that is already been updated and the second one shows a phone that has made the request to download the firmware.

 

08/13/2009 09:43:47,[email protected],192.168.1.25,UCPhone,8/13/2009 9:43:35 AM,"001B9E2CCC19","1108010762","Polycom","CX700","A","ENU",cpe.nbt;1.0.522.101;8/12/2008 2:17:07 PM,http://OCS2.DOMAIN123.ORG/DeviceUpdateFiles_Int/UCPhone/Polycom/CX700/A/ENU/3.5.6907.35/CPE/CPE.nbt;3.5.6907.35;6/27/2009 10:28:10 AM

08/13/2009 09:58:15,,192.168.1.25,UCPhone,8/13/2009 6:53:44 AM,"001B9E2CCC19","1108010762","Polycom","CX700","A","ENU",cpe.nbt;3.5.6907.35;6/27/2009 10:28:10 AM,

 

08/13/2009 10:01:56,[email protected],192.168.2.22,UCPhone,8/12/2009 6:16:38 PM,"001B9E2CC773","1108009571","Polycom","CX700","A","ENU",cpe.nbt;1.0.522.101;8/12/2008 2:17:07 PM,http://OCS2.DOMAIN123.ORG/DeviceUpdateFiles_Int/UCPhone/Polycom/CX700/A/ENU/3.5.6907.35/CPE/CPE.nbt;3.5.6907.35;6/27/2009 10:28:10 AM

 

 

This should hopefully be posted as a support article on TechNet soon.

 

If you are having any other issues with the Update Service, Rui Silva has written a great troubleshooting post here. You should also go through the Communicator Phone Edition R2 Deployment Guide.

New Office Communicator IP Endpoints (snom 820 working!)

Snom + OCS Part 2 – Victory

Presence status = In a call (on a real phone!)

Let's face it sometimes a "real" hard phone is just what the doctored ordered.

When I walk into my home office and my laptop computer is not turned on and my desktop phone is being used by my kids to play Sims or Spore, a USB phone isn't going to do the trick.

Enter the snom phones.

In part 1, I wrote about our partial success setting up the snom 820 phones that act as Office Communicator end points.

Thanks to the technical support people at snom and a new firmware update to address some ICE issues, the snom 820 is now working fully and working well.

The web-based interface that is built into the snom 820 is very extensive.

To update the firmware, I navigated to the software update page (see below).

I then specified the URL to the location on our web server where I put the .bin file and clicked the "Load" button. The phone display showed the loading and validation process and then rebooted with the new firware while retaining all of my device settings.

I pushed the "Directory" button, selected a contact whose presence status was showing as available and clicked to call. Everything worked just as it should.

So far we've done some additional call flow testing and things are working fine.

Interestingly the "early media" supported by OCS R2 seems to work much faster on the snom phone than on the "Tanjay" I have right beside it. With the snom phone there is no need to pause before saying "hello" – this is a very good thing.

I will follow-up with a more detailed post shortly that will include results from the additional snom 820, snom 300 and snom 360 tests.

Presence status = Available (Enjoying the simplicity of answering calls on a real phone)