Runtime Phone Firmware Version Determination

[Andy Backus]

I am upgrading firmware 7945, 7965, 7975s from 8.3.4SR1 to 9.2.1. 

After first reload, I would say 50% did not take. The 'Firmware Load Information' report shows no devices running non-default images, perfect, except

when I http, many are on old load..

I checked the CUCM Reporter function and connot find any tools to show which devices are not up to date. So I have to http to EACH phone

to check the load, then issue 'reset' like 5 times before the phone finally gets upgraded.  Very time consuming, very frustrating.  This current upgrade

is only 200 phones, my next is 3000+.  It has been recommended to use a 3rd party product called Clarus to confirm loads.

It is unfathomable that there is not a tool to tell runtime firmware version, heck, even a published sql command would be fine.  That, and why are soo many resets required! 

Am I doing something wrong?

Steps I have taken

They should be using the default specified 9.2.1. 

- I loaded cop on pub and sub

- I restarted TFP service on pub only (not running on sub)

- I tftp'd down some of the failed SEP############.cnf.xml files and confirmed the load listing

- RTMT shows no CPU load on servers and no failed TFTP requests

Any help here would be appreciated.

Thank you

Andy

[jonathan.dixon]

Hi Andy,

Have you tried the ‘Unified CM Phones With Mismatched Load’ report under Cisco Unified Reporting (https://IPOfCUCM:8443/cucreports)? This is fairly accurate in my experience. Also you could do a device search under RTMT (go to CallManager / Device Search / Phone).  Otherwise as you mention there are third party tools like the Uplinx Report Tool for Cisco UC (http://www.uplinx.com/reporttool.htm) which http to every phone for you and compile load information amongst other things. It’s not free unfortunately and the demo version’s phone report is limited to 30 phones.

I’m assuming the phones that fail to upgrade are running version 8.3(3) at least? (minimum required to go to 9.2(1)) as you say they upgrade sucessfully after a few resets. I’ve seen 6961 phones refuse to upgrade at all unless they’re power cycled, haven’t seen this behaviour with 79xx phones though. Are the phones that are failing to upgrade on remote sites? We see this quite a lot, TFTP is not the best method to copy data over long distances as it gets slower as the RTT from the TFTP server increases. You could play with peer firmware sharing – this in theory should allow phones of the same type to get firmware off a local phone which has upgraded successfully.

You're not doing anything wrong, it happens and yes it's frustrating!  Thankfully Cisco seems to be moving away from TFTP as a method to distribute firmware.

Regards,

Jonathan

[Andy Backus]

Thanks for the reply Jonathan. 

I did review the cureports but it seems that the mismatch load option is not availalable in 6.1(2).  I am very happy to hear that there is a tool in subsequent releases though and I will have to check that out.  I did note the interim 8.3(3) requirement in the release notes but that did not apply since we were already at 8.3(4).  All the phones are in the same campus and I did not see any indicators that the TFTP server (pub) was stressed.  To prove that, I would still get the same result doing as few as 5; really, even had the same doing multiple resets on same phone (even put the image in device config on a few with same result). 

Thank you for the Uplinx, cureporter, and peer TFTP notes.  Will defintely look at the last item given that we have WAN link constraints on another project.

Again, thank you!