I think we've got to remember a lot of different types of customers use CUCM.
I've got some customers that need the ease of use with the COP file updating the device defaults automatically. I actually use this method most of the time as well and just revert the device default change before restarting TFTP and resetting any phones. The device packs and upgrades are a bit annoying to me with it changing all my phone firmware. I usually Bulk Export then Device Defaults and re-import after to avoid this. With upgrades, some phones begin upgrading before I can switch this back though. I think some customers would just never update device firmware if it didn't force it on them though. On Tue, May 1, 2018 at 1:04 PM, Anthony Holloway < [email protected]> wrote: > Thanks, now I want to watch that movie again. It's been a looong time. > > I can agree that support is not black and white. Though, do consider the > Cisco Partner's perspective, when Customers ask for recommendations on what > they should be doing. Our responses should always be motivated by keeping > them on supported combinations of: configurations, hardware, and software. > > And back to my original point, having firmware delivered via CUCM upgrades > and Device Packs is hurting that effort, because the collateral upgrading > which is occurring, is seldom what you want. I.e., Production is not ready > for the new firmware, or it's older than what you are already running. > > Case in point: I have a customer right now with ones of thousands of > phones, looking to add support for the Webex Room Kit device, so we need a > Device Pack, but they are not ready to roll out a major firmware upgrade > from 11.x to 12.x on all of their 78/8800 series phones. Therefore, I have > to now dance around the firmware upgrade, in what should be an otherwise > easy task of applying support for just this specific device model. > > I'd be curious to know how many people are actually delivering phone > firmware via Device Packs, versus CUCM upgrades, versus COP files, versus > ZIPs. > > For me, it goes like this: > > 1. CUCM Upgrades are for upgrading CUCM, I typically freeze the existing > phone firmware upgrades (and will do them pre- or post-upgrade of CUCM) > 2. Device Packs are for adding support for newer models, I typically > freeze the existing phone firmware upgrades > 3. COP Files are almost never used for upgrading phone firmware, they > change the device defaults, when my intention is never to upgrade 100% of a > model right from the start (pilot first) > *If COPs didn't change device defaults, I'd likely use these over ZIP > files. Do these restart TFTP automatically? I cannot recall. > 4. ZIP Files are my preferred approach, because they are low risk because > I can easily control their distribution in the environment (like running a > pilot first) > > > > On Mon, Apr 30, 2018 at 12:45 PM Ryan Ratliff (rratliff) < > [email protected]> wrote: > >> Since Cisco already drops *support* for all firmware older than the most >> recent firmware: >> >> >> “You keep using that word, I do not think it means what you think it >> means”. >> >> In all seriousness, and as the author of the document you quoted, there’s >> a reason why the bulk of that document is dedicated to explaining the fact >> that that the word “support” can mean many things, and even lists examples >> to highlight this point. >> >> I would also like to point out the fact that said document describes >> itself as a “policy”, and policies don’t exist in a vacuum. They exist >> because there are situations that require them to be applied, and it’s >> generally helpful when a company you work with to publicly document >> whatever policy they are applying to you. Equally important is that you are >> told exactly how and why that policy is being applied to your situation. >> >> All of that said my point is that the word “support” gets thrown around a >> lot in the customer *support* business. We all should be certain to >> explain exactly what version of the word we mean when using it, and if you >> find yourself on the receiving end of a policy that limits some form of >> support for which you feel you are entitled, you owe it to yourself and the >> other person to ask for clarification. >> >> Anyone that can’t provide that clarification or context is either being >> lazy or doesn’t know what they are talking about. >> >> -Ryan >> >> On Apr 30, 2018, at 9:06 AM, Anthony Holloway < >> [email protected]> wrote: >> >> I wish CUCM didn't ship with newer phone firmware. >> >> Since Cisco already drops support for all firmware older than the most >> recent firmware: >> >> - For each IP Phone model, once Cisco releases a new firmware version, >> the older versions are no longer supported. >> - Cisco expects customers who encounter a problem on an older version of >> firmware to test the latest firmware on a subset of phones in order to >> confirm that the problem still exists. >> Source: http://www.cisco.com/c/en/us/support/docs/collaboration- >> endpoints/unified-ip-phone-7900-series/116684-technote-ipphone-00.html >> >> And most people agree that you should upgrade firmware before a CUCM >> upgrade anyway, just remove firmware from CUCM. >> >> Not too mention it clutters up TFTP. >> >> I also think that the firmware should be decoupled from the Device >> Packs. When adding support for a single model phone, rarely am I also >> trying to upgrade 100% of the phones in the environment too. >> >> On Sun, Apr 29, 2018 at 8:22 PM Charles Goldsmith <[email protected]> >> wrote: >> >>> Since the 8832 is a dual bank phone, shouldn't it have the old image on >>> it in the backup bank? Maybe hardcoding the old image on the phone >>> configuration and doing a reset will cause it to boot from it? >>> >>> >>> On Sun, Apr 29, 2018 at 7:06 PM Ryan Huff <[email protected]> wrote: >>> >>>> Sounds like the ole’ ‘step upgrade’ issue that plagued the 79xx series >>>> back in the 8.x days .... >>>> >>>> My guess is they don’t actually need RMA’ed, just the easiest way to >>>> deal with it .... >>>> >>>> I’d flash the phones and advertise an isolated tftp server to them with >>>> the firmware load and XML bootstrap file. The phones aren’t working now, so >>>> flashing them and then still not getting them to load right isn’t going to >>>> make it any worse. >>>> >>>> Use DNS in the DHCP scope in your isolation network with the TFTP >>>> server and pcap/debug the DNS queries to see the bootstrap and load files >>>> it’s looking for. >>>> >>>> In the 79xx series back in the day when I would perform this Lazarus >>>> trick for some lucky customers; the bootstrap filename was >>>> XMLDefault.cnf.xml. Not sure if it’s the same nowadays though. >>>> >>>> Here is the Cisco doc on the procedure for the older stuff .... worth a >>>> shot but not sure if it still works on the newer gear. >>>> >>>> https://www.cisco.com/c/en/us/support/docs/unified- >>>> communications/unified-communications-manager- >>>> callmanager/200582-Update-Cisco-IP-Phone-Firmware-through-T.html >>>> >>>> >>>> -Ryan- >>>> >>>> On Apr 29, 2018, at 18:53, Jason Aarons (Americas) < >>>> [email protected]> wrote: >>>> >>>> >>>> >>>> >>>> I have a customer with four 8832 conference room phones. Their CUCM was >>>> running version 12.0.1 of the 8832 firmware. These phones shipped with >>>> version 12.0.1SR2. When they registered the first two phones they >>>> downgraded from 12.0.1SR2 to 12.0.1 and are now unusable. They sit on >>>> “Connecting” after booting up. They do not get an IP address. You cannot >>>> set an IP address manually. If you reset the phone it doesn’t fix it, nor >>>> does a factory reset >>>> <https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cuipph/8832/english/adminguide/cs88_b_conference-8832-admin-guide-cucm/cs88_b_conference-8832-admin-guide-cucm_chapter_01011.html> >>>> allow >>>> the phone to revert to the firmware they shipped with. Cisco TAC says they >>>> must be RMA’d. We upgraded CUCM to 12.0.1SR3 and the other two phones >>>> upgraded fine from 12.0.1SR2 to 12.0.1SR3. >>>> >>>> Does anyone have any ideas on what we could do to fix these phones >>>> other than RMAing them? >>>> >>>> >>>> >>>> Get Outlook for Android <https://aka.ms/ghei36> >>>> >>>> >>>> >>>> This email and all contents are subject to the following disclaimer: >>>> "http://www.dimensiondata.com/emaildisclaimer"; >>>> <http://www.dimensiondata.com/Global/Policies/Pages/Email-Disclaimer.aspx> >>>> >>>> _______________________________________________ >>>> cisco-voip mailing list >>>> [email protected] >>>> https://puck.nether.net/mailman/listinfo/cisco-voip >>>> >>>> _______________________________________________ >>>> cisco-voip mailing list >>>> [email protected] >>>> https://puck.nether.net/mailman/listinfo/cisco-voip >>>> >>> _______________________________________________ >>> cisco-voip mailing list >>> [email protected] >>> https://puck.nether.net/mailman/listinfo/cisco-voip >>> >> _______________________________________________ >> cisco-voip mailing list >> [email protected] >> https://puck.nether.net/mailman/listinfo/cisco-voip >> >> > _______________________________________________ > cisco-voip mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/cisco-voip > >
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
