Re: [cisco-voip] 8832s

[DJ Lundberg]

I had a similar issue with 8832s not getting an IP address running any
firmware lower than 12.0.1SR2.  Give this a shot:


*   On CUCM Upgrade the firmware to the latest release.
  *   Boot the 8832 phone from inactive load.
 *   Hold the * key while connecting the power to the 8832.
 *   After the LED bar light turns ON green and then OFF, you can
release the * key.
 *   The 8832 should proceed to boot from the image in the alternate
partition.

Thanks,
DJ

On Sun, Jun 10, 2018 at 9:54 AM, Jason Aarons (Americas) <
jason.aar...@dimensiondata.com> wrote:

> I would only deploy a device pack on new cluster build.  All else per
> device update.  I used to like to hardcode the load field on a per phone
> basis to prevent them from changing.  Been doing less of that.
>
>
>
> The cmterm CE (Collaboration Endpoint) loads of 1.8GB are ridiculous, in
> DRS .tar backups too.
>
>
>
> *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] *On Behalf
> Of *Anthony Holloway
> *Sent:* Monday, April 30, 2018 9:07 AM
> *To:* Charles Goldsmith 
> *Cc:* cisco-voip (cisco-voip@puck.nether.net) 
> *Subject:* Re: [cisco-voip] 8832s
>
>
>
>
>
> 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 
> 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  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) <
> jason.aar...@dimensiondata.com> 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 tw

Re: [cisco-voip] 8832s

[Jason Aarons (Americas)]

I would only deploy a device pack on new cluster build.  All else per device 
update.  I used to like to hardcode the load field on a per phone basis to 
prevent them from changing.  Been doing less of that.

The cmterm CE (Collaboration Endpoint) loads of 1.8GB are ridiculous, in DRS 
.tar backups too.

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Anthony Holloway
Sent: Monday, April 30, 2018 9:07 AM
To: Charles Goldsmith 
Cc: cisco-voip (cisco-voip@puck.nether.net) 
Subject: Re: [cisco-voip] 8832s


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<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 
mailto:wo...@justfamily.org>> 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 
mailto:ryanh...@outlook.com>> 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<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) 
mailto:jason.aar...@dimensiondata.com>> 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
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip<https://puck.nether.net/mailman/listinfo/cisco-voip>
___
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/

Re: [cisco-voip] 8832s

[Anthony Holloway]

"...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 
wrote:

> With the new Cisco Headsets that adds another level of software management
> too ;)
>
> Stephen
>
> On 1 May 2018, at 20:34, Brian Meade  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 <
> avholloway+cisco-v...@gmail.com> 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  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 <
>>> avholloway+cisco-v...@gmail.com> 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 

Re: [cisco-voip] 8832s

[Stephen Welsh]

With the new Cisco Headsets that adds another level of software management too 
;)

Stephen

On 1 May 2018, at 20:34, Brian Meade > 
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 
> 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 
> 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 
> 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) 
> 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 

Re: [cisco-voip] 8832s

[Brian Meade]

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 <
avholloway+cisco-v...@gmail.com> 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  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 <
>> avholloway+cisco-v...@gmail.com> 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) <
>>> rratl...@cisco.com> 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 

Re: [cisco-voip] 8832s

[Ryan Ratliff (rratliff)]

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.

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.

"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.

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.

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.
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.

-Ryan

On May 1, 2018, at 2:46 PM, Ryan Huff 
> wrote:

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

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.

In Communications Manager, right under SRST Reference, Call it, CUS Server -or 
better yet, resurrect a use for “Application Server”.

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”.

You could even get fancy and allow an option the choose update time ... etc

I’m just saying, Anthony is right IMO, could be a lot simpler and easier.

On May 1, 2018, at 14:32, Anthony Holloway 
> wrote:

M, popcorn.

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.

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.

On Tue, May 1, 2018 at 12:27 PM Ryan Huff 
> wrote:
[image1.jpeg]


On May 1, 2018, at 13:17, Anthony Holloway 
> 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 

Re: [cisco-voip] 8832s

[Anthony Holloway]

"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  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 <
> avholloway+cisco-v...@gmail.com> 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) <
>> rratl...@cisco.com> 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 

Re: [cisco-voip] 8832s

[Brian Meade]

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 <
avholloway+cisco-v...@gmail.com> 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) <
> rratl...@cisco.com> 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 <
>> avholloway+cisco-v...@gmail.com> 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 

Re: [cisco-voip] 8832s

[Ryan Huff]

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

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.

In Communications Manager, right under SRST Reference, Call it, CUS Server -or 
better yet, resurrect a use for “Application Server”.

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”.

You could even get fancy and allow an option the choose update time ... etc

I’m just saying, Anthony is right IMO, could be a lot simpler and easier.

On May 1, 2018, at 14:32, Anthony Holloway 
> wrote:

M, popcorn.

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.

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.

On Tue, May 1, 2018 at 12:27 PM Ryan Huff 
> wrote:
[image1.jpeg]


On May 1, 2018, at 13:17, Anthony Holloway 
> 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) 
> 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 

Re: [cisco-voip] 8832s

[Anthony Holloway]

M, popcorn.

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.

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.

On Tue, May 1, 2018 at 12:27 PM Ryan Huff  wrote:

> [image: image1.jpeg]
>
>
> On May 1, 2018, at 13:17, Anthony Holloway <
> avholloway+cisco-v...@gmail.com> 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) <
> rratl...@cisco.com> 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 <
>> avholloway+cisco-v...@gmail.com> wrote:
>>
>> I wish CUCM didn't ship with newer phone firmware.
>>
>> Since Cisco already drops support for all firmware 

Re: [cisco-voip] 8832s

[Ryan Huff]

[image1.jpeg]

On May 1, 2018, at 13:17, Anthony Holloway 
> 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) 
> 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 
> 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 
> 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 

Re: [cisco-voip] 8832s

[Anthony Holloway]

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) 
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 <
> avholloway+cisco-v...@gmail.com> 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 
> 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  wrote:
>>

Re: [cisco-voip] 8832s

[Ryan Ratliff (rratliff)]

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 
> 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 
> 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 
> 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) 
> 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
 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 

Re: [cisco-voip] 8832s

[Anthony Holloway]

Old is exactly the reason too!

Cisco is making you keep up to date with the phone firmware versions, and
inevitability, that means your phones will out pace CUCM.

Oh and CUCM firmware info is in Read Me, bottom-ish of document.

E.g.,
https://www.cisco.com/web/software/282074295/141143/cucm-readme-1151su4.pdf

Look for "Firmware Versions in this Release"


On Mon, Apr 30, 2018 at 8:18 AM Lelio Fulgenzi <le...@uoguelph.ca> wrote:

> But in this case, it was “older” firmware on CUCM. ☹
>
>
>
> It’s not always very clear which version will be available in the CUCM
> version. I remember it was easy. They would list default firmware versions
> per version. Now it’s a bit harder to find.
>
>
>
>
>
>
>
> ---
>
> *Lelio Fulgenzi, B.A.* | Senior Analyst
>
> Computing and Communications Services | University of Guelph
>
> Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON |
> N1G 2W1
>
> 519-824-4120 Ext. 56354 <(519)%20824-4120> | le...@uoguelph.ca
>
>
>
> www.uoguelph.ca/ccs | @UofGCCS on Instagram, Twitter and Facebook
>
>
>
> [image: image001.png]
>
>
>
> *From:* cisco-voip <cisco-voip-boun...@puck.nether.net> *On Behalf Of *Anthony
> Holloway
> *Sent:* Monday, April 30, 2018 9:07 AM
> *To:* Charles Goldsmith <wo...@justfamily.org>
> *Cc:* cisco-voip (cisco-voip@puck.nether.net) <cisco-voip@puck.nether.net>
> *Subject:* Re: [cisco-voip] 8832s
>
>
>
> 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 <wo...@justfamily.org>
> 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 <ryanh...@outlook.com> 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) <
> jason.aar...@dimensiondata.com> 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 fact

Re: [cisco-voip] 8832s

[Joe Martini]

Hi Jason,

Please try booting from the alternate image as Charles mentioned.  Here is the 
process for the 8832 phones.

1. Hold the * key while connecting the power to the 8832.
2. After the LED bar light turns ON green and then OFF, you can release the * 
key.
3. The 8832 should proceed to boot from the image in the alternate partition.

The problem is caused by the older (downgraded) firmware not recognizing the 
USB-C to ethernet adapter the phone is using, therefore no network 
connectivity.  If you can boot off the image that the phone came with the 
ethernet adapter will be detected.

We are making changes to prevent the phone from downgrading to a version that 
is not compatible with the connected ethernet adapter.

Joe

On Apr 30, 2018, at 9:18 AM, Lelio Fulgenzi <le...@uoguelph.ca> wrote:

But in this case, it was “older” firmware on CUCM. ☹
 
It’s not always very clear which version will be available in the CUCM version. 
I remember it was easy. They would list default firmware versions per version. 
Now it’s a bit harder to find.
 
 
 
---
Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1
519-824-4120 Ext. 56354 | le...@uoguelph.ca <mailto:le...@uoguelph.ca>
 
www.uoguelph.ca/ccs <http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, 
Twitter and Facebook
 

 
From: cisco-voip <cisco-voip-boun...@puck.nether.net> On Behalf Of Anthony 
Holloway
Sent: Monday, April 30, 2018 9:07 AM
To: Charles Goldsmith <wo...@justfamily.org>
Cc: cisco-voip (cisco-voip@puck.nether.net) <cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] 8832s
 
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
 
<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 <wo...@justfamily.org 
<mailto:wo...@justfamily.org>> 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 <ryanh...@outlook.com 
<mailto:ryanh...@outlook.com>> 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
 
<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) 
<jason.aar...@dimensiondata.com <mailto:jason.aar...@dimensiondata.com>> 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

Re: [cisco-voip] 8832s

[Lelio Fulgenzi]

But in this case, it was “older” firmware on CUCM. ☹

It’s not always very clear which version will be available in the CUCM version. 
I remember it was easy. They would list default firmware versions per version. 
Now it’s a bit harder to find.



---
Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1
519-824-4120 Ext. 56354 | le...@uoguelph.ca<mailto:le...@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, 
Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

From: cisco-voip <cisco-voip-boun...@puck.nether.net> On Behalf Of Anthony 
Holloway
Sent: Monday, April 30, 2018 9:07 AM
To: Charles Goldsmith <wo...@justfamily.org>
Cc: cisco-voip (cisco-voip@puck.nether.net) <cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] 8832s

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 
<wo...@justfamily.org<mailto:wo...@justfamily.org>> 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 
<ryanh...@outlook.com<mailto:ryanh...@outlook.com>> 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) 
<jason.aar...@dimensiondata.com<mailto:jason.aar...@dimensiondata.com>> 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
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_

Re: [cisco-voip] 8832s

[Anthony Holloway]

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 
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  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) <
>> jason.aar...@dimensiondata.com> 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
>> 
>>  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 
>>
>>
>>
>> This email and all contents are subject to the following disclaimer:
>> "http://www.dimensiondata.com/emaildisclaimer;
>> 
>>
>> ___
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>> ___
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] 8832s

[Charles Goldsmith]

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  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) <
> jason.aar...@dimensiondata.com> 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
> 
>  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 
>
>
>
> This email and all contents are subject to the following disclaimer:
> "http://www.dimensiondata.com/emaildisclaimer;
> 
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] 8832s

[Ryan Huff]

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) 
> 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
 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



This email and all contents are subject to the following disclaimer:
"http://www.dimensiondata.com/emaildisclaimer;
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[cisco-voip] 8832s

[Jason Aarons (Americas)]

   
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
 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

This email and all contents are subject to the following disclaimer:

"http://www.dimensiondata.com/emaildisclaimer;
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip