<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
In my head PCD is this server. What it doesn’t have (yet?) is the hook back to Cisco where it can notify you that an upgrade is available (for every collab product you have) and let you install/stage/deploy to your alpha users/schedule/ignore. The PM for the
product gets it, but like any product there’s what you want to do and what you have the resources to do.
<div class=""><br class="">
</div>
<div class="">There are some cool things in the works for upgrades, and when we finally get there it should be a thousand times better than what it is today. </div>
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">
<div style="font-family: LucidaGrande;" class="">"I think some customers would just never update device firmware if it didn't force it on them though."</div>
<div style="font-family: LucidaGrande;" class=""><br class="">
</div>
<div style="font-family: LucidaGrande;" class="">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.</div>
</blockquote>
</div>
<div class=""><br class="">
</div>
<div class="">I agree that upgrades don’t happen the same for everyone. There was an entire “hypothetical” I took out of my email about the customer case that got us to create that policy doc in the first place. </div>
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<div class="">
<div class="gmail_quote">
<div dir="auto" class="">
<div class="">
<div dir="ltr" class="">
<div class="">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.</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</blockquote>
This is an excellent point, and my answer would be to run the latest available unless you have a good reason not to. All of the “support” pieces align nicely from end customer to partner, to TAC, to the BU behind TAC. When those pieces get out of alignment
customers can get into very ugly situations, and in most cases I bet the partner takes the full brunt of that pain. </div>
<div class=""><br class="">
<div class="">
<div class="">-Ryan </div>
<div><br class="">
<div class="">On May 1, 2018, at 2:46 PM, Ryan Huff <<a href="mailto:ryanhuff@outlook.com" class="">ryanhuff@outlook.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="auto" class="">Phone firmware should be decoupled from the whole process and be it’s own, simpler entity. Long gone are the Celsius days where one load essentially applied to everything
<div class=""><br class="">
</div>
<div class="">Take one of those Red Hat Kernel licenses laying around and make a “Cisco UC Update Server”, version specific and pre-packed with all the COPs and SUs. You did it with licensing, why not firmware? Hell, thrown in an Aptitude or YUM source (that’s
APT for you civilian types) and have it auto update the COPs and SUs from the Cisco mothership. I’m sure you can figure out how to license it ... lol.</div>
<div class=""><br class="">
</div>
<div class="">In Communications Manager, right under SRST Reference, Call it, CUS Server -or better yet, resurrect a use for “Application Server”.</div>
<div class=""><br class="">
</div>
<div class="">Then, in ad-hoc fashion, on the device configuration page, or en mass through the device pool, a simple option; “allow device to query new firmware”.</div>
<div class=""><br class="">
</div>
<div class="">You could even get fancy and allow an option the choose update time ... etc<br class="">
<br class="">
<div class="">I’m just saying, Anthony is right IMO, could be a lot simpler and easier.</div>
<div class=""><br class="">
On May 1, 2018, at 14:32, Anthony Holloway <<a href="mailto:avholloway+cisco-voip@gmail.com" class="">avholloway+cisco-voip@gmail.com</a>> wrote:<br class="">
<br class="">
</div>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">Mmmmm, popcorn.
<div class=""><br class="">
</div>
<div class="">I feel like it's less about the word "support" for me, and more about the delivery of phone firmware. Ryan R. just happened to address that one piece, of the larger thing I was saying. I feel passionate about the OP's story, since I too have
been impacted by the phone firmware upgrade/downgrade process; I'm going through that pain right now with the Webex Room Kit Device Pack.</div>
<div class=""><br class="">
</div>
<div class="">Latest device pack for CUCM 11.0 is 11.0(1.24087), which contains 8832 12.0(1) firmware, but 12.0(1)SR3 has been out for 5 months, and therefore, I too would break my phones, if I didn't prevent my phones from updating during the Device Pack process.
All just to add the one model. I'm just saying: the process is not as good as it could be, and I'm trying to voice my opinion on it. There are some people reading this, who don't deal with this process very often, and may learn that it's not as easy or simple
as one might think.</div>
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="">On Tue, May 1, 2018 at 12:27 PM Ryan Huff <<a href="mailto:ryanhuff@outlook.com" class="">ryanhuff@outlook.com</a>> wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto" class=""><img src="cid:FE57FDE1-9C14-48D9-BE08-5478929821FB" alt="image1.jpeg" id="m_4468761027572981631FE57FDE1-9C14-48D9-BE08-5478929821FB" class=""></div>
<div dir="auto" class=""><br class="">
<div class=""><br class="">
On May 1, 2018, at 13:17, Anthony Holloway <<a href="mailto:avholloway+cisco-voip@gmail.com" target="_blank" class="">avholloway+cisco-voip@gmail.com</a>> wrote:<br class="">
<br class="">
</div>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">Thanks, now I want to watch that movie again. It's been a looong time.
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">For me, it goes like this:</div>
<div class=""><br class="">
</div>
<div class="">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)</div>
<div class="">2. Device Packs are for adding support for newer models, I typically freeze the existing phone firmware upgrades</div>
<div class="">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)</div>
<div class=""> *If COPs didn't change device defaults, I'd likely use these over ZIP files. Do these restart TFTP automatically? I cannot recall.</div>
<div class="">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)</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="">On Mon, Apr 30, 2018 at 12:45 PM Ryan Ratliff (rratliff) <<a href="mailto:rratliff@cisco.com" target="_blank" class="">rratliff@cisco.com</a>> wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word;line-break:after-white-space" class="">
<blockquote type="cite" class="">
<div class="">Since Cisco already drops <u class=""><font size="4" class="">support</font></u> for all firmware older than the most recent firmware:</div>
<div class=""><br class="">
</div>
</blockquote>
<div class=""><br class="">
</div>
</div>
<div style="word-wrap:break-word;line-break:after-white-space" class="">
<div class="">“You keep using that word, I do not think it means what you think it means”.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">All of that said my point is that the word “support” gets thrown around a lot in the customer
<b class="">support</b> 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.</div>
<div class=""><br class="">
</div>
<div class="">Anyone that can’t provide that clarification or context is either being lazy or doesn’t know what they are talking about. </div>
</div>
<div style="word-wrap:break-word;line-break:after-white-space" class=""><br class="">
<div class="">-Ryan </div>
</div>
<div style="word-wrap:break-word;line-break:after-white-space" class="">
<div class=""><br class="">
<div class="">On Apr 30, 2018, at 9:06 AM, Anthony Holloway <<a href="mailto:avholloway+cisco-voip@gmail.com" target="_blank" class="">avholloway+cisco-voip@gmail.com</a>> wrote:</div>
<br class="m_4468761027572981631m_8054382222143210456Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">I wish CUCM didn't ship with newer phone firmware.
<div class=""><br class="">
</div>
<div class="">Since Cisco already drops support for all firmware older than the most recent firmware:</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">- For each IP Phone model, once Cisco releases a new firmware version, the older versions are no longer supported.</div>
<div class="">- 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.<br class="">
</div>
<div class="">Source: <a href="http://www.cisco.com/c/en/us/support/docs/collaboration-endpoints/unified-ip-phone-7900-series/116684-technote-ipphone-00.html" target="_blank" class="">
http://www.cisco.com/c/en/us/support/docs/collaboration-endpoints/unified-ip-phone-7900-series/116684-technote-ipphone-00.html</a></div>
</div>
<div class=""><br class="">
</div>
<div class="">And most people agree that you should upgrade firmware before a CUCM upgrade anyway, just remove firmware from CUCM.</div>
<div class=""><br class="">
</div>
<div class="">Not too mention it clutters up TFTP.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="">On Sun, Apr 29, 2018 at 8:22 PM Charles Goldsmith <<a href="mailto:wokka@justfamily.org" target="_blank" class="">wokka@justfamily.org</a>> wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr" class="">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?
<div class=""><br class="">
</div>
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="">On Sun, Apr 29, 2018 at 7:06 PM Ryan Huff <<a href="mailto:ryanhuff@outlook.com" target="_blank" class="">ryanhuff@outlook.com</a>> wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto" class="">Sounds like the ole’ ‘step upgrade’ issue that plagued the 79xx series back in the 8.x days ....
<div class=""><br class="">
</div>
<div class="">My guess is they don’t actually need RMA’ed, just the easiest way to deal with it .... </div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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. </div>
<div class=""><br class="">
</div>
<div class="">In the 79xx series back in the day when I would perform this Lazarus trick for some lucky customers; the bootstrap filename was <span style="margin:0px;padding:0px;border:0px;font-weight:700;font-stretch:inherit;line-height:inherit;vertical-align:baseline;background-color:rgba(255,255,255,0)" class="">XMLDefault.cnf.xml. </span>Not
sure if it’s the same nowadays though.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class=""><a href="https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/200582-Update-Cisco-IP-Phone-Firmware-through-T.html" target="_blank" class="">https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/200582-Update-Cisco-IP-Phone-Firmware-through-T.html</a></div>
</div>
<div dir="auto" class="">
<div class=""><br class="">
<div class=""><br class="">
</div>
<div class="">-Ryan-</div>
</div>
</div>
<div dir="auto" class="">
<div class="">
<div class=""><br class="">
On Apr 29, 2018, at 18:53, Jason Aarons (Americas) <<a href="mailto:jason.aarons@dimensiondata.com" target="_blank" class="">jason.aarons@dimensiondata.com</a>> wrote:<br class="">
<br class="">
</div>
<blockquote type="cite" class="">
<div class=""><br class="">
<br class="">
<div align="left" class="">
<div dir="auto" style="direction:ltr;margin:0px;padding:0px;font-family:sans-serif;font-size:11pt" class="">
<br class="">
</div>
<div dir="auto" style="direction:ltr;margin:0px;padding:0px;font-family:sans-serif;font-size:11pt" class="">
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 <a href="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" target="_blank" class="">factory
reset</a> 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.<br class="">
</div>
</div>
<div align="left" class="">
<div dir="auto" style="direction:ltr;margin:0px;padding:0px;font-family:sans-serif;font-size:11pt" class="">
<br class="">
</div>
</div>
<div align="left" class="">
<div dir="auto" style="direction:ltr;margin:0px;padding:0px;font-family:sans-serif;font-size:11pt" class="">
Does anyone have any ideas on what we could do to fix these phones other than RMAing them?<br class="">
</div>
</div>
<div align="left" class="">
<div dir="auto" style="direction:ltr;margin:0px;padding:0px;font-family:sans-serif;font-size:11pt" class="">
<br class="">
</div>
</div>
<div dir="auto" style="direction:ltr;margin:0px;padding:0px;font-family:sans-serif;font-size:11pt" class="">
<br class="">
<br class="">
</div>
<div dir="auto" style="direction:ltr;margin:0px;padding:0px;font-family:sans-serif;font-size:11pt" class="">
<div dir="auto" style="direction:ltr;margin:0px;padding:0px;font-family:sans-serif;font-size:11pt" class="">
Get <a href="https://aka.ms/ghei36" target="_blank" class="">Outlook for Android</a></div>
<br class="">
</div>
<br class="">
<br class="">
<font class="">This email and all contents are subject to the following disclaimer:<br class="">
<a href="http://www.dimensiondata.com/Global/Policies/Pages/Email-Disclaimer.aspx" target="_blank" class="">"http://www.dimensiondata.com/emaildisclaimer"</a>
</font><font color="white" class=""></font></div>
</blockquote>
<blockquote type="cite" class="">
<div class=""><span class="">_______________________________________________</span><br class="">
<span class="">cisco-voip mailing list</span><br class="">
<span class=""><a href="mailto:cisco-voip@puck.nether.net" target="_blank" class="">cisco-voip@puck.nether.net</a></span><br class="">
<span class=""><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank" class="">https://puck.nether.net/mailman/listinfo/cisco-voip</a></span><br class="">
</div>
</blockquote>
</div>
</div>
_______________________________________________<br class="">
cisco-voip mailing list<br class="">
<a href="mailto:cisco-voip@puck.nether.net" target="_blank" class="">cisco-voip@puck.nether.net</a><br class="">
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="noreferrer" target="_blank" class="">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br class="">
</blockquote>
</div>
_______________________________________________<br class="">
cisco-voip mailing list<br class="">
<a href="mailto:cisco-voip@puck.nether.net" target="_blank" class="">cisco-voip@puck.nether.net</a><br class="">
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="noreferrer" target="_blank" class="">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br class="">
</blockquote>
</div>
_______________________________________________<br class="">
cisco-voip mailing list<br class="">
<a href="mailto:cisco-voip@puck.nether.net" target="_blank" class="">cisco-voip@puck.nether.net</a><br class="">
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank" class="">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br class="">
</div>
</div>
<br class="">
</div>
</blockquote>
</div>
</div>
</blockquote>
<blockquote type="cite" class="">
<div class=""><span class="">_______________________________________________</span><br class="">
<span class="">cisco-voip mailing list</span><br class="">
<span class=""><a href="mailto:cisco-voip@puck.nether.net" target="_blank" class="">cisco-voip@puck.nether.net</a></span><br class="">
<span class=""><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank" class="">https://puck.nether.net/mailman/listinfo/cisco-voip</a></span><br class="">
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
<br class="">
</div>
</div>
</body>
</html>