Recently, I upgraded from Call Manager 4.1.3(sr8a) to CUCM 7.0(2) and about 99.8% of my phones migrated over properly to the new phone system. The other 0.2% associate fine to the new CUCM 7, but the firmware didn't either get pushed out or the phone didn't try to grab new firmware. All my other 7970's upgraded just fine. The phones in question work fine so I partially don't want to mess with it, but I would like to get every phone on the same revision that the new CUCM 7 offers. Does anyone know what I could do to force a phone to take the firmware that's installed on my server?
We're seeing many similar cases caused by phone load signing issue. Try the note here:
I see that it lists what the default load should be for the phones (which the 7970's in question do not have), but
what are the steps I would have to go through to get them to take the new firmware?
I was specifically referring to the note just below the html anchor:
Note: For all SCCP and SIP phone firmware upgrades from versions earlier than 8.3(3) to Version 8.5(2)SR1 or later, you must first upgrade your firmware to Version 8.5(2). Once you have upgraded to Version 8.5(2), you can upgrade your IP Phone to Version 8.5(2)SR1 or later.
For additional details, firmware download locations, and firmware upgrade instructions, please see
I've ran through all those steps and it still seems like that phone hasn't decided to update. Would I need to open a TAC case on this?
What version of code is on the misbehaving phones?
What version of code are the good phones going to?
Have you verified what the phone is pulling from TFTP when it starts up?
This is what I wrote down from the 'bad' phone:
Boot Load ID:
This is what I wrote down from a 'good' phone:
Boot Load ID:
I'm not sure what I need to do to verify what the phone is doing while it tries to pull from the specified TFTP server (which is the same as one of my subscribers), but when I go into the 'bad' phone's IPv4 settings, it shows the TFTP server having the same ip as my subscriber server (as I have it setup for when it pulls it's DHCP information).
If that is not the issue then we'd need to start from the basics. Verify how the phone identifies its TFTP server, veirfy connectivity to the TFTP server, review the phone console log, review detailed TFTP server traces, and possibly review packet capture taken from back of phone with "span to pc" enabled or form a span of the switchport where the phone connects.
That would be good data to collect for opening a TAC case. If you do not see an issue in the data then provide to TAC and we can give a second opinion.
I'm trying out the forums. I am a bit challenged by this source not being indexed by google where cisco-voip is.