"...I bet the partner takes the full brunt of that pain." Ryan R., You have just made my day! Thank you.
And Brian, I'm right there with you on the TFTP/MOH/Announcement sync topic. Ping me via Spark if you'd like to brain storm a bulk upload to TFTP solution together. Or if you already know how you'd do it, I'd love to hear about it on Spark nonetheless. On Tue, May 1, 2018 at 2:45 PM Stephen Welsh <[email protected]> wrote: > With the new Cisco Headsets that adds another level of software management > too ;) > > Stephen > > On 1 May 2018, at 20:34, Brian Meade <[email protected]> wrote: > > I can't believe there's still no syncing of TFTP/MOH Files or at least > making it the default option. Uploading things to every node > over-complicates things. And TFTP File Management has no bulk upload which > is super annoying when I rebuild subscribers on an upgrade. I keep meaning > to make a script for that bulk TFTP upload. > > There definitely needs to be some overhaul of phone firmware management. > > We'll probably just see the phones start reaching out to the Webex cloud > nightly to update their phone firmware as we further this cloud transition. > > We have to make sure this stuff doesn't get too easy for the customers and > kill off all our jobs too :P > > On Tue, May 1, 2018 at 3:25 PM, Anthony Holloway < > [email protected]> wrote: > >> "With upgrades, some phones begin upgrading before I can switch this back >> though." >> >> I've had this happen more times than I'm comfortable admitting, and >> especially, I've already set the expectation that phones will not upgrade. >> >> Installing the COP and then changing the Device Defaults is six of one >> and a half-dozen of the other, when compared to uploading the few files in >> the ZIP, and not touching the defaults. To each his own, of course. >> >> "I think some customers would just never update device firmware if it >> didn't force it on them though." >> >> There are people still running 2800 ISRs, MCS, CUCM 7.x, and even 7940s. >> Is firmware really the place to start forcing people to modernize? I think >> it would be best to let the customer choose, unless they move to a cloud >> based solution. >> >> On Tue, May 1, 2018 at 2:13 PM Brian Meade <[email protected]> wrote: >> >>> 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 > > >
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
