Re: [cisco-voip] UCM Upgrade Poll

[Lelio Fulgenzi]

Super! Thanks.

Sent from my iPhone

On Aug 28, 2017, at 12:30 AM, Charles Goldsmith 
> wrote:

I should have looked at that link a bit closer, it doesn't mention the cop 
file: 
http://www.cisco.com/web/software/282204704/18582/CleanupCommonCOPfilev1.4.pdf

Which is the 3rd method, but there is a caveat, so read it closely.

On Sun, Aug 27, 2017 at 11:25 PM, Charles Goldsmith 
> wrote:
There is!

http://docwiki.cisco.com/wiki/Unified_CM_L2_Upgrade_Disk_Space_issues#Free_Up_Space_for_Unified_CM_L2_Upgrade.C2.A0

That entire page is good reading.


On Sun, Aug 27, 2017 at 11:20 PM, Lelio Fulgenzi 
> wrote:
Are there instructions on how to free up disk space?

Sent from my iPhone

On Aug 27, 2017, at 11:18 PM, Erick Bergquist 
> wrote:

I've done a few dozen inplace upgrades of CUCM, Unity, UCCX with existing VMs 
with no real issues over the past few years. Talking 8.x to 10.x  or 11.x or 
9.x to 10/11.x.

Issues encountered:

Freeing up disk space on existing VM for the RU/SU to install on a few upgrades 
(more of a slow down)

Recently had issue with IM 9.x to 11.x where a invalid ntp entry was in the 
platformcfg.xml XML file that there is a bug ID on that TAC had to get in with 
root access to remove. After that the IM inplace upgrade went fine.

And a few non-upgrade issues involving license matters and getting correct 
number of licenses.

I was reading another post about 12.0 using CentOS now, need to read that over 
more and see what is changing with upgrade process.


My only wish was if these would go faster. Maybe have an incremental patch with 
just fixes instead of a full size SU/install file and reinstalling every file - 
especially for SU patches within same major version.

YMMV, Erick


On Thu, Aug 24, 2017 at 10:34 AM, Anthony Holloway 
> wrote:
Why not just come along with me on my next upgrade.  You can feel the 
pain...err excitement, of planning and executing an upgrade in the real world.  
;)

On Thu, Aug 24, 2017 at 9:52 AM Ryan Ratliff (rratliff) 
> wrote:
Thanks everyone for the feedback.

We are looking at ways to make upgrades easier and stories like these are very 
helpful.

-Ryan

On Aug 24, 2017, at 10:17 AM, Scott Voll 
> wrote:

1. I'm guessing we are 10% True bugs and 90% environment, but I will agree with 
other comments about DNS and NTP being a dumb reason to fail

2. as for time, over the years we used to spend over 6 months on upgrades.. 
we are down to about 2 months.  in our enviroment we have to document all the 
changes before so it can be communicated to the end user.  Researching for the 
answers has moved from Anthony's 100 documents to just opening a TAC case.  It 
has become way to time consuming to find all the right doc's to get the correct 
answer.

YMMV

Scott


On Wed, Aug 23, 2017 at 1:46 PM, Anthony Holloway 
> wrote:
Wow, it's kind of cool that you're even asking.  Thanks for that.

Already I can see this is going to be a wide gap in responses. Partner vs end 
user, this customer vs that customer, this version vs that version, this 
scenario vs that one, and on, and on, and on.

1) I feel like it's always a bug (100%), in that, developers should code 
solutions that can work around most issues.  E.g., I had an upgrade fail on a 
CUCM because the ntp was 0.us.pool.ntp.org, despite 
CUCM happily syncing to it in the current version.  OR Common partition not 
having enough space, when devs could just purge old logs to make room, or 
simply make better logs to begin with (I do admit, moving to compress logs 
[TAR/GZ] was sweet)

2) This is a painful one for me, but I put in a lot of time preparing for an 
upgrade.  A large portion of the time is, in my opinion, wasted finding the 
right documentation and then trying to interpret it.  Here's a fun one: there's 
over 100 documents an Engineer needs to reference in preparation for what I 
would consider a low-medium level environment.  I've posted this before, but 
I'll post it again, I have a matrix of documents I need to reference during the 
planning and execution phase of an upgrade:

[http://cisco-voip.markmail.org/download.xqy?id=rrs3zlxbamemgodr=1]


On Wed, Aug 23, 2017 at 8:38 AM Ryan Ratliff (rratliff) 
> wrote:
Quick 2 question poll, feel free to unicast or share your response with the 
group.

1. When you or your customers have a UCM or IMP upgrade fail, what percentage 
of failures are due to a bug vs something in the environment (user error, db 
updates, etc)?
% bug:
% not a bug:
Yes it’s a very 

Re: [cisco-voip] UCM Upgrade Poll

[Erick Bergquist]

Yep. Besides the steps in docs above,

The expand space cop file if the upgrade needs you to change the disk space
for new version per OVA template specs.

The RTMT low watermark trick works very well, but sometimes doesn't free up
quite enough so then you need to manually go find files to clear.

Check your MoH files -- once had a system with dozens of larger size MoH
files. Had to temp remove some of them to gain space and put them back
afterward.

TFTP files -- I usually delete the larger ones (DX650s, CIUS, etc).   (file
list tftp * detail size) if needed. Usually, a very small % of disk
reclaimed on newer versions.

Check for packet capture files under platform/cli



On Sun, Aug 27, 2017 at 10:30 PM, Charles Goldsmith 
wrote:

> I should have looked at that link a bit closer, it doesn't mention the cop
> file: http://www.cisco.com/web/software/282204704/18582/
> CleanupCommonCOPfilev1.4.pdf
>
> Which is the 3rd method, but there is a caveat, so read it closely.
>
> On Sun, Aug 27, 2017 at 11:25 PM, Charles Goldsmith 
> wrote:
>
>> There is!
>>
>> http://docwiki.cisco.com/wiki/Unified_CM_L2_Upgrade_Disk_Spa
>> ce_issues#Free_Up_Space_for_Unified_CM_L2_Upgrade.C2.A0
>>
>> That entire page is good reading.
>>
>>
>> On Sun, Aug 27, 2017 at 11:20 PM, Lelio Fulgenzi 
>> wrote:
>>
>>> Are there instructions on how to free up disk space?
>>>
>>> Sent from my iPhone
>>>
>>> On Aug 27, 2017, at 11:18 PM, Erick Bergquist 
>>> wrote:
>>>
>>> I've done a few dozen inplace upgrades of CUCM, Unity, UCCX with
>>> existing VMs with no real issues over the past few years. Talking 8.x to
>>> 10.x  or 11.x or 9.x to 10/11.x.
>>>
>>> Issues encountered:
>>>
>>> Freeing up disk space on existing VM for the RU/SU to install on a few
>>> upgrades (more of a slow down)
>>>
>>> Recently had issue with IM 9.x to 11.x where a invalid ntp entry was
>>> in the platformcfg.xml XML file that there is a bug ID on that TAC had to
>>> get in with root access to remove. After that the IM inplace upgrade went
>>> fine.
>>>
>>> And a few non-upgrade issues involving license matters and getting
>>> correct number of licenses.
>>>
>>> I was reading another post about 12.0 using CentOS now, need to read
>>> that over more and see what is changing with upgrade process.
>>>
>>>
>>> My only wish was if these would go faster. Maybe have an incremental
>>> patch with just fixes instead of a full size SU/install file and
>>> reinstalling every file - especially for SU patches within same major
>>> version.
>>>
>>> YMMV, Erick
>>>
>>>
>>> On Thu, Aug 24, 2017 at 10:34 AM, Anthony Holloway <
>>> avholloway+cisco-v...@gmail.com> wrote:
>>>
 Why not just come along with me on my next upgrade.  You can feel the
 pain...err excitement, of planning and executing an upgrade in the real
 world.  ;)

 On Thu, Aug 24, 2017 at 9:52 AM Ryan Ratliff (rratliff) <
 rratl...@cisco.com> wrote:

> Thanks everyone for the feedback.
>
> We are looking at ways to make upgrades easier and stories like these
> are very helpful.
>
> -Ryan
>
> On Aug 24, 2017, at 10:17 AM, Scott Voll  wrote:
>
> 1. I'm guessing we are 10% True bugs and 90% environment, but I will
> agree with other comments about DNS and NTP being a dumb reason to fail
>
> 2. as for time, over the years we used to spend over 6 months on
> upgrades.. we are down to about 2 months.  in our enviroment we have 
> to
> document all the changes before so it can be communicated to the end user.
> Researching for the answers has moved from Anthony's 100 documents to just
> opening a TAC case.  It has become way to time consuming to find all the
> right doc's to get the correct answer.
>
> YMMV
>
> Scott
>
>
> On Wed, Aug 23, 2017 at 1:46 PM, Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
>> Wow, it's kind of cool that you're even asking.  Thanks for that.
>>
>> Already I can see this is going to be a wide gap in responses.
>> Partner vs end user, this customer vs that customer, this version vs that
>> version, this scenario vs that one, and on, and on, and on.
>>
>> 1) I feel like it's always a bug (100%), in that, developers should
>> code solutions that can work around most issues.  E.g., I had an upgrade
>> fail on a CUCM because the ntp was 0.us.pool.ntp.org, despite CUCM
>> happily syncing to it in the current version.  OR Common partition not
>> having enough space, when devs could just purge old logs to make room, or
>> simply make better logs to begin with (I do admit, moving to compress 
>> logs
>> [TAR/GZ] was sweet)
>>
>> 2) This is a painful one for me, but I put in a lot of time preparing
>> for an upgrade.  A large portion of the time is, in my opinion, wasted
>> 

Re: [cisco-voip] UCM Upgrade Poll

[Charles Goldsmith]

I should have looked at that link a bit closer, it doesn't mention the cop
file:
http://www.cisco.com/web/software/282204704/18582/CleanupCommonCOPfilev1.4.pdf


Which is the 3rd method, but there is a caveat, so read it closely.

On Sun, Aug 27, 2017 at 11:25 PM, Charles Goldsmith 
wrote:

> There is!
>
> http://docwiki.cisco.com/wiki/Unified_CM_L2_Upgrade_Disk_
> Space_issues#Free_Up_Space_for_Unified_CM_L2_Upgrade.C2.A0
>
> That entire page is good reading.
>
>
> On Sun, Aug 27, 2017 at 11:20 PM, Lelio Fulgenzi 
> wrote:
>
>> Are there instructions on how to free up disk space?
>>
>> Sent from my iPhone
>>
>> On Aug 27, 2017, at 11:18 PM, Erick Bergquist  wrote:
>>
>> I've done a few dozen inplace upgrades of CUCM, Unity, UCCX with existing
>> VMs with no real issues over the past few years. Talking 8.x to 10.x  or
>> 11.x or 9.x to 10/11.x.
>>
>> Issues encountered:
>>
>> Freeing up disk space on existing VM for the RU/SU to install on a few
>> upgrades (more of a slow down)
>>
>> Recently had issue with IM 9.x to 11.x where a invalid ntp entry was in
>> the platformcfg.xml XML file that there is a bug ID on that TAC had to get
>> in with root access to remove. After that the IM inplace upgrade went
>> fine.
>>
>> And a few non-upgrade issues involving license matters and getting
>> correct number of licenses.
>>
>> I was reading another post about 12.0 using CentOS now, need to read that
>> over more and see what is changing with upgrade process.
>>
>>
>> My only wish was if these would go faster. Maybe have an incremental
>> patch with just fixes instead of a full size SU/install file and
>> reinstalling every file - especially for SU patches within same major
>> version.
>>
>> YMMV, Erick
>>
>>
>> On Thu, Aug 24, 2017 at 10:34 AM, Anthony Holloway <
>> avholloway+cisco-v...@gmail.com> wrote:
>>
>>> Why not just come along with me on my next upgrade.  You can feel the
>>> pain...err excitement, of planning and executing an upgrade in the real
>>> world.  ;)
>>>
>>> On Thu, Aug 24, 2017 at 9:52 AM Ryan Ratliff (rratliff) <
>>> rratl...@cisco.com> wrote:
>>>
 Thanks everyone for the feedback.

 We are looking at ways to make upgrades easier and stories like these
 are very helpful.

 -Ryan

 On Aug 24, 2017, at 10:17 AM, Scott Voll  wrote:

 1. I'm guessing we are 10% True bugs and 90% environment, but I will
 agree with other comments about DNS and NTP being a dumb reason to fail

 2. as for time, over the years we used to spend over 6 months on
 upgrades.. we are down to about 2 months.  in our enviroment we have to
 document all the changes before so it can be communicated to the end user.
 Researching for the answers has moved from Anthony's 100 documents to just
 opening a TAC case.  It has become way to time consuming to find all the
 right doc's to get the correct answer.

 YMMV

 Scott


 On Wed, Aug 23, 2017 at 1:46 PM, Anthony Holloway <
 avholloway+cisco-v...@gmail.com> wrote:

> Wow, it's kind of cool that you're even asking.  Thanks for that.
>
> Already I can see this is going to be a wide gap in responses. Partner
> vs end user, this customer vs that customer, this version vs that version,
> this scenario vs that one, and on, and on, and on.
>
> 1) I feel like it's always a bug (100%), in that, developers should
> code solutions that can work around most issues.  E.g., I had an upgrade
> fail on a CUCM because the ntp was 0.us.pool.ntp.org, despite CUCM
> happily syncing to it in the current version.  OR Common partition not
> having enough space, when devs could just purge old logs to make room, or
> simply make better logs to begin with (I do admit, moving to compress logs
> [TAR/GZ] was sweet)
>
> 2) This is a painful one for me, but I put in a lot of time preparing
> for an upgrade.  A large portion of the time is, in my opinion, wasted
> finding the right documentation and then trying to interpret it.  Here's a
> fun one: there's over 100 documents an Engineer needs to reference in
> preparation for what I would consider a low-medium level environment.  
> I've
> posted this before, but I'll post it again, I have a matrix of documents I
> need to reference during the planning and execution phase of an upgrade:
>
>
>
>
> On Wed, Aug 23, 2017 at 8:38 AM Ryan Ratliff (rratliff) <
> rratl...@cisco.com> wrote:
>
>> Quick 2 question poll, feel free to unicast or share your response
>> with the group.
>>
>> 1. When you or your customers have a UCM or IMP upgrade fail, what
>> percentage of failures are due to a bug vs something in the environment
>> (user error, db updates, etc)?
>> % bug:
>> % not a bug:
>> Yes it’s a very subjective question but 

Re: [cisco-voip] UCM Upgrade Poll

[Charles Goldsmith]

There is!

http://docwiki.cisco.com/wiki/Unified_CM_L2_Upgrade_Disk_Space_issues#Free_Up_Space_for_Unified_CM_L2_Upgrade.C2.A0


That entire page is good reading.


On Sun, Aug 27, 2017 at 11:20 PM, Lelio Fulgenzi  wrote:

> Are there instructions on how to free up disk space?
>
> Sent from my iPhone
>
> On Aug 27, 2017, at 11:18 PM, Erick Bergquist  wrote:
>
> I've done a few dozen inplace upgrades of CUCM, Unity, UCCX with existing
> VMs with no real issues over the past few years. Talking 8.x to 10.x  or
> 11.x or 9.x to 10/11.x.
>
> Issues encountered:
>
> Freeing up disk space on existing VM for the RU/SU to install on a few
> upgrades (more of a slow down)
>
> Recently had issue with IM 9.x to 11.x where a invalid ntp entry was in
> the platformcfg.xml XML file that there is a bug ID on that TAC had to get
> in with root access to remove. After that the IM inplace upgrade went
> fine.
>
> And a few non-upgrade issues involving license matters and getting correct
> number of licenses.
>
> I was reading another post about 12.0 using CentOS now, need to read that
> over more and see what is changing with upgrade process.
>
>
> My only wish was if these would go faster. Maybe have an incremental patch
> with just fixes instead of a full size SU/install file and reinstalling
> every file - especially for SU patches within same major version.
>
> YMMV, Erick
>
>
> On Thu, Aug 24, 2017 at 10:34 AM, Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
>> Why not just come along with me on my next upgrade.  You can feel the
>> pain...err excitement, of planning and executing an upgrade in the real
>> world.  ;)
>>
>> On Thu, Aug 24, 2017 at 9:52 AM Ryan Ratliff (rratliff) <
>> rratl...@cisco.com> wrote:
>>
>>> Thanks everyone for the feedback.
>>>
>>> We are looking at ways to make upgrades easier and stories like these
>>> are very helpful.
>>>
>>> -Ryan
>>>
>>> On Aug 24, 2017, at 10:17 AM, Scott Voll  wrote:
>>>
>>> 1. I'm guessing we are 10% True bugs and 90% environment, but I will
>>> agree with other comments about DNS and NTP being a dumb reason to fail
>>>
>>> 2. as for time, over the years we used to spend over 6 months on
>>> upgrades.. we are down to about 2 months.  in our enviroment we have to
>>> document all the changes before so it can be communicated to the end user.
>>> Researching for the answers has moved from Anthony's 100 documents to just
>>> opening a TAC case.  It has become way to time consuming to find all the
>>> right doc's to get the correct answer.
>>>
>>> YMMV
>>>
>>> Scott
>>>
>>>
>>> On Wed, Aug 23, 2017 at 1:46 PM, Anthony Holloway <
>>> avholloway+cisco-v...@gmail.com> wrote:
>>>
 Wow, it's kind of cool that you're even asking.  Thanks for that.

 Already I can see this is going to be a wide gap in responses. Partner
 vs end user, this customer vs that customer, this version vs that version,
 this scenario vs that one, and on, and on, and on.

 1) I feel like it's always a bug (100%), in that, developers should
 code solutions that can work around most issues.  E.g., I had an upgrade
 fail on a CUCM because the ntp was 0.us.pool.ntp.org, despite CUCM
 happily syncing to it in the current version.  OR Common partition not
 having enough space, when devs could just purge old logs to make room, or
 simply make better logs to begin with (I do admit, moving to compress logs
 [TAR/GZ] was sweet)

 2) This is a painful one for me, but I put in a lot of time preparing
 for an upgrade.  A large portion of the time is, in my opinion, wasted
 finding the right documentation and then trying to interpret it.  Here's a
 fun one: there's over 100 documents an Engineer needs to reference in
 preparation for what I would consider a low-medium level environment.  I've
 posted this before, but I'll post it again, I have a matrix of documents I
 need to reference during the planning and execution phase of an upgrade:




 On Wed, Aug 23, 2017 at 8:38 AM Ryan Ratliff (rratliff) <
 rratl...@cisco.com> wrote:

> Quick 2 question poll, feel free to unicast or share your response
> with the group.
>
> 1. When you or your customers have a UCM or IMP upgrade fail, what
> percentage of failures are due to a bug vs something in the environment
> (user error, db updates, etc)?
> % bug:
> % not a bug:
> Yes it’s a very subjective question but that’s ok, use your judgement.
>
> 2. When an upgrade goes smoothly with no issues, how much time do you
> put into the planning and preparation for the upgrade (not the execution)?
>
> Thanks,
>
> -Ryan
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>

 

Re: [cisco-voip] UCM Upgrade Poll

[Lelio Fulgenzi]

Are there instructions on how to free up disk space?

Sent from my iPhone

On Aug 27, 2017, at 11:18 PM, Erick Bergquist 
> wrote:

I've done a few dozen inplace upgrades of CUCM, Unity, UCCX with existing VMs 
with no real issues over the past few years. Talking 8.x to 10.x  or 11.x or 
9.x to 10/11.x.

Issues encountered:

Freeing up disk space on existing VM for the RU/SU to install on a few upgrades 
(more of a slow down)

Recently had issue with IM 9.x to 11.x where a invalid ntp entry was in the 
platformcfg.xml XML file that there is a bug ID on that TAC had to get in with 
root access to remove. After that the IM inplace upgrade went fine.

And a few non-upgrade issues involving license matters and getting correct 
number of licenses.

I was reading another post about 12.0 using CentOS now, need to read that over 
more and see what is changing with upgrade process.


My only wish was if these would go faster. Maybe have an incremental patch with 
just fixes instead of a full size SU/install file and reinstalling every file - 
especially for SU patches within same major version.

YMMV, Erick


On Thu, Aug 24, 2017 at 10:34 AM, Anthony Holloway 
> wrote:
Why not just come along with me on my next upgrade.  You can feel the 
pain...err excitement, of planning and executing an upgrade in the real world.  
;)

On Thu, Aug 24, 2017 at 9:52 AM Ryan Ratliff (rratliff) 
> wrote:
Thanks everyone for the feedback.

We are looking at ways to make upgrades easier and stories like these are very 
helpful.

-Ryan

On Aug 24, 2017, at 10:17 AM, Scott Voll 
> wrote:

1. I'm guessing we are 10% True bugs and 90% environment, but I will agree with 
other comments about DNS and NTP being a dumb reason to fail

2. as for time, over the years we used to spend over 6 months on upgrades.. 
we are down to about 2 months.  in our enviroment we have to document all the 
changes before so it can be communicated to the end user.  Researching for the 
answers has moved from Anthony's 100 documents to just opening a TAC case.  It 
has become way to time consuming to find all the right doc's to get the correct 
answer.

YMMV

Scott


On Wed, Aug 23, 2017 at 1:46 PM, Anthony Holloway 
> wrote:
Wow, it's kind of cool that you're even asking.  Thanks for that.

Already I can see this is going to be a wide gap in responses. Partner vs end 
user, this customer vs that customer, this version vs that version, this 
scenario vs that one, and on, and on, and on.

1) I feel like it's always a bug (100%), in that, developers should code 
solutions that can work around most issues.  E.g., I had an upgrade fail on a 
CUCM because the ntp was 0.us.pool.ntp.org, despite 
CUCM happily syncing to it in the current version.  OR Common partition not 
having enough space, when devs could just purge old logs to make room, or 
simply make better logs to begin with (I do admit, moving to compress logs 
[TAR/GZ] was sweet)

2) This is a painful one for me, but I put in a lot of time preparing for an 
upgrade.  A large portion of the time is, in my opinion, wasted finding the 
right documentation and then trying to interpret it.  Here's a fun one: there's 
over 100 documents an Engineer needs to reference in preparation for what I 
would consider a low-medium level environment.  I've posted this before, but 
I'll post it again, I have a matrix of documents I need to reference during the 
planning and execution phase of an upgrade:

[http://cisco-voip.markmail.org/download.xqy?id=rrs3zlxbamemgodr=1]


On Wed, Aug 23, 2017 at 8:38 AM Ryan Ratliff (rratliff) 
> wrote:
Quick 2 question poll, feel free to unicast or share your response with the 
group.

1. When you or your customers have a UCM or IMP upgrade fail, what percentage 
of failures are due to a bug vs something in the environment (user error, db 
updates, etc)?
% bug:
% not a bug:
Yes it’s a very subjective question but that’s ok, use your judgement.

2. When an upgrade goes smoothly with no issues, how much time do you put into 
the planning and preparation for the upgrade (not the execution)?

Thanks,

-Ryan

___
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

Re: [cisco-voip] UCM Upgrade Poll

[Erick Bergquist]

I've done a few dozen inplace upgrades of CUCM, Unity, UCCX with existing
VMs with no real issues over the past few years. Talking 8.x to 10.x  or
11.x or 9.x to 10/11.x.

Issues encountered:

Freeing up disk space on existing VM for the RU/SU to install on a few
upgrades (more of a slow down)

Recently had issue with IM 9.x to 11.x where a invalid ntp entry was in
the platformcfg.xml XML file that there is a bug ID on that TAC had to get
in with root access to remove. After that the IM inplace upgrade went
fine.

And a few non-upgrade issues involving license matters and getting correct
number of licenses.

I was reading another post about 12.0 using CentOS now, need to read that
over more and see what is changing with upgrade process.


My only wish was if these would go faster. Maybe have an incremental patch
with just fixes instead of a full size SU/install file and reinstalling
every file - especially for SU patches within same major version.

YMMV, Erick


On Thu, Aug 24, 2017 at 10:34 AM, Anthony Holloway <
avholloway+cisco-v...@gmail.com> wrote:

> Why not just come along with me on my next upgrade.  You can feel the
> pain...err excitement, of planning and executing an upgrade in the real
> world.  ;)
>
> On Thu, Aug 24, 2017 at 9:52 AM Ryan Ratliff (rratliff) <
> rratl...@cisco.com> wrote:
>
>> Thanks everyone for the feedback.
>>
>> We are looking at ways to make upgrades easier and stories like these are
>> very helpful.
>>
>> -Ryan
>>
>> On Aug 24, 2017, at 10:17 AM, Scott Voll  wrote:
>>
>> 1. I'm guessing we are 10% True bugs and 90% environment, but I will
>> agree with other comments about DNS and NTP being a dumb reason to fail
>>
>> 2. as for time, over the years we used to spend over 6 months on
>> upgrades.. we are down to about 2 months.  in our enviroment we have to
>> document all the changes before so it can be communicated to the end user.
>> Researching for the answers has moved from Anthony's 100 documents to just
>> opening a TAC case.  It has become way to time consuming to find all the
>> right doc's to get the correct answer.
>>
>> YMMV
>>
>> Scott
>>
>>
>> On Wed, Aug 23, 2017 at 1:46 PM, Anthony Holloway <
>> avholloway+cisco-v...@gmail.com> wrote:
>>
>>> Wow, it's kind of cool that you're even asking.  Thanks for that.
>>>
>>> Already I can see this is going to be a wide gap in responses. Partner
>>> vs end user, this customer vs that customer, this version vs that version,
>>> this scenario vs that one, and on, and on, and on.
>>>
>>> 1) I feel like it's always a bug (100%), in that, developers should code
>>> solutions that can work around most issues.  E.g., I had an upgrade fail on
>>> a CUCM because the ntp was 0.us.pool.ntp.org, despite CUCM happily
>>> syncing to it in the current version.  OR Common partition not having
>>> enough space, when devs could just purge old logs to make room, or simply
>>> make better logs to begin with (I do admit, moving to compress logs
>>> [TAR/GZ] was sweet)
>>>
>>> 2) This is a painful one for me, but I put in a lot of time preparing
>>> for an upgrade.  A large portion of the time is, in my opinion, wasted
>>> finding the right documentation and then trying to interpret it.  Here's a
>>> fun one: there's over 100 documents an Engineer needs to reference in
>>> preparation for what I would consider a low-medium level environment.  I've
>>> posted this before, but I'll post it again, I have a matrix of documents I
>>> need to reference during the planning and execution phase of an upgrade:
>>>
>>>
>>>
>>>
>>> On Wed, Aug 23, 2017 at 8:38 AM Ryan Ratliff (rratliff) <
>>> rratl...@cisco.com> wrote:
>>>
 Quick 2 question poll, feel free to unicast or share your response with
 the group.

 1. When you or your customers have a UCM or IMP upgrade fail, what
 percentage of failures are due to a bug vs something in the environment
 (user error, db updates, etc)?
 % bug:
 % not a bug:
 Yes it’s a very subjective question but that’s ok, use your judgement.

 2. When an upgrade goes smoothly with no issues, how much time do you
 put into the planning and preparation for the upgrade (not the execution)?

 Thanks,

 -Ryan

 ___
 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] UCM Upgrade Poll

[Anthony Holloway]

Why not just come along with me on my next upgrade.  You can feel the
pain...err excitement, of planning and executing an upgrade in the real
world.  ;)

On Thu, Aug 24, 2017 at 9:52 AM Ryan Ratliff (rratliff) 
wrote:

> Thanks everyone for the feedback.
>
> We are looking at ways to make upgrades easier and stories like these are
> very helpful.
>
> -Ryan
>
> On Aug 24, 2017, at 10:17 AM, Scott Voll  wrote:
>
> 1. I'm guessing we are 10% True bugs and 90% environment, but I will agree
> with other comments about DNS and NTP being a dumb reason to fail
>
> 2. as for time, over the years we used to spend over 6 months on
> upgrades.. we are down to about 2 months.  in our enviroment we have to
> document all the changes before so it can be communicated to the end user.
> Researching for the answers has moved from Anthony's 100 documents to just
> opening a TAC case.  It has become way to time consuming to find all the
> right doc's to get the correct answer.
>
> YMMV
>
> Scott
>
>
> On Wed, Aug 23, 2017 at 1:46 PM, Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
>> Wow, it's kind of cool that you're even asking.  Thanks for that.
>>
>> Already I can see this is going to be a wide gap in responses. Partner vs
>> end user, this customer vs that customer, this version vs that version,
>> this scenario vs that one, and on, and on, and on.
>>
>> 1) I feel like it's always a bug (100%), in that, developers should code
>> solutions that can work around most issues.  E.g., I had an upgrade fail on
>> a CUCM because the ntp was 0.us.pool.ntp.org, despite CUCM happily
>> syncing to it in the current version.  OR Common partition not having
>> enough space, when devs could just purge old logs to make room, or simply
>> make better logs to begin with (I do admit, moving to compress logs
>> [TAR/GZ] was sweet)
>>
>> 2) This is a painful one for me, but I put in a lot of time preparing for
>> an upgrade.  A large portion of the time is, in my opinion, wasted finding
>> the right documentation and then trying to interpret it.  Here's a fun one:
>> there's over 100 documents an Engineer needs to reference in preparation
>> for what I would consider a low-medium level environment.  I've posted this
>> before, but I'll post it again, I have a matrix of documents I need to
>> reference during the planning and execution phase of an upgrade:
>>
>>
>>
>>
>> On Wed, Aug 23, 2017 at 8:38 AM Ryan Ratliff (rratliff) <
>> rratl...@cisco.com> wrote:
>>
>>> Quick 2 question poll, feel free to unicast or share your response with
>>> the group.
>>>
>>> 1. When you or your customers have a UCM or IMP upgrade fail, what
>>> percentage of failures are due to a bug vs something in the environment
>>> (user error, db updates, etc)?
>>> % bug:
>>> % not a bug:
>>> Yes it’s a very subjective question but that’s ok, use your judgement.
>>>
>>> 2. When an upgrade goes smoothly with no issues, how much time do you
>>> put into the planning and preparation for the upgrade (not the execution)?
>>>
>>> Thanks,
>>>
>>> -Ryan
>>>
>>> ___
>>> 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] UCM Upgrade Poll

[Ryan Ratliff (rratliff)]

Thanks everyone for the feedback.

We are looking at ways to make upgrades easier and stories like these are very 
helpful.

-Ryan

On Aug 24, 2017, at 10:17 AM, Scott Voll 
> wrote:

1. I'm guessing we are 10% True bugs and 90% environment, but I will agree with 
other comments about DNS and NTP being a dumb reason to fail

2. as for time, over the years we used to spend over 6 months on upgrades.. 
we are down to about 2 months.  in our enviroment we have to document all the 
changes before so it can be communicated to the end user.  Researching for the 
answers has moved from Anthony's 100 documents to just opening a TAC case.  It 
has become way to time consuming to find all the right doc's to get the correct 
answer.

YMMV

Scott


On Wed, Aug 23, 2017 at 1:46 PM, Anthony Holloway 
> wrote:
Wow, it's kind of cool that you're even asking.  Thanks for that.

Already I can see this is going to be a wide gap in responses. Partner vs end 
user, this customer vs that customer, this version vs that version, this 
scenario vs that one, and on, and on, and on.

1) I feel like it's always a bug (100%), in that, developers should code 
solutions that can work around most issues.  E.g., I had an upgrade fail on a 
CUCM because the ntp was 0.us.pool.ntp.org, despite 
CUCM happily syncing to it in the current version.  OR Common partition not 
having enough space, when devs could just purge old logs to make room, or 
simply make better logs to begin with (I do admit, moving to compress logs 
[TAR/GZ] was sweet)

2) This is a painful one for me, but I put in a lot of time preparing for an 
upgrade.  A large portion of the time is, in my opinion, wasted finding the 
right documentation and then trying to interpret it.  Here's a fun one: there's 
over 100 documents an Engineer needs to reference in preparation for what I 
would consider a low-medium level environment.  I've posted this before, but 
I'll post it again, I have a matrix of documents I need to reference during the 
planning and execution phase of an upgrade:

[http://cisco-voip.markmail.org/download.xqy?id=rrs3zlxbamemgodr=1]


On Wed, Aug 23, 2017 at 8:38 AM Ryan Ratliff (rratliff) 
> wrote:
Quick 2 question poll, feel free to unicast or share your response with the 
group.

1. When you or your customers have a UCM or IMP upgrade fail, what percentage 
of failures are due to a bug vs something in the environment (user error, db 
updates, etc)?
% bug:
% not a bug:
Yes it’s a very subjective question but that’s ok, use your judgement.

2. When an upgrade goes smoothly with no issues, how much time do you put into 
the planning and preparation for the upgrade (not the execution)?

Thanks,

-Ryan

___
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] UCM Upgrade Poll

[Scott Voll]

1. I'm guessing we are 10% True bugs and 90% environment, but I will agree
with other comments about DNS and NTP being a dumb reason to fail

2. as for time, over the years we used to spend over 6 months on
upgrades.. we are down to about 2 months.  in our enviroment we have to
document all the changes before so it can be communicated to the end user.
Researching for the answers has moved from Anthony's 100 documents to just
opening a TAC case.  It has become way to time consuming to find all the
right doc's to get the correct answer.

YMMV

Scott


On Wed, Aug 23, 2017 at 1:46 PM, Anthony Holloway <
avholloway+cisco-v...@gmail.com> wrote:

> Wow, it's kind of cool that you're even asking.  Thanks for that.
>
> Already I can see this is going to be a wide gap in responses. Partner vs
> end user, this customer vs that customer, this version vs that version,
> this scenario vs that one, and on, and on, and on.
>
> 1) I feel like it's always a bug (100%), in that, developers should code
> solutions that can work around most issues.  E.g., I had an upgrade fail on
> a CUCM because the ntp was 0.us.pool.ntp.org, despite CUCM happily
> syncing to it in the current version.  OR Common partition not having
> enough space, when devs could just purge old logs to make room, or simply
> make better logs to begin with (I do admit, moving to compress logs
> [TAR/GZ] was sweet)
>
> 2) This is a painful one for me, but I put in a lot of time preparing for
> an upgrade.  A large portion of the time is, in my opinion, wasted finding
> the right documentation and then trying to interpret it.  Here's a fun one:
> there's over 100 documents an Engineer needs to reference in preparation
> for what I would consider a low-medium level environment.  I've posted this
> before, but I'll post it again, I have a matrix of documents I need to
> reference during the planning and execution phase of an upgrade:
>
>
>
>
> On Wed, Aug 23, 2017 at 8:38 AM Ryan Ratliff (rratliff) <
> rratl...@cisco.com> wrote:
>
>> Quick 2 question poll, feel free to unicast or share your response with
>> the group.
>>
>> 1. When you or your customers have a UCM or IMP upgrade fail, what
>> percentage of failures are due to a bug vs something in the environment
>> (user error, db updates, etc)?
>> % bug:
>> % not a bug:
>> Yes it’s a very subjective question but that’s ok, use your judgement.
>>
>> 2. When an upgrade goes smoothly with no issues, how much time do you put
>> into the planning and preparation for the upgrade (not the execution)?
>>
>> Thanks,
>>
>> -Ryan
>>
>> ___
>> 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] UCM Upgrade Poll

[Bill Talley]

1.  That's kind of a loaded question.   90% bugs where  bugs also includes the 
system is "functioning as designed".  Most failures I've encountered, as a 
partner, occur as a result of the applications heavy reliance on DNS (if 
configured) and NTP.  Would be nice if there was an option to bypass the error 
and proceed based on host file entries or hardware clock as opposed to outright 
failing because let's say, there are two different PTR records for the same 
host or DNS/NTP are down for maintenance (different server group).  I get the 
security/reliability piece of it, but why can't the developers permit the 
upgrade to complete and present the same  "DNS is unreachable/invalid" or "NTP 
is unreachable" message after the upgrade completes like they any other time of 
operation?

2.  Same amount of planning as I do when upgrades fail, about 8-12 hours.

Thanks for asking for feedback.


Sent from a mobile device with very tiny touchscreen input keys. Please excude 
my typtos.

> On Aug 23, 2017, at 8:37 AM, Ryan Ratliff (rratliff)  
> wrote:
> 
> Quick 2 question poll, feel free to unicast or share your response with the 
> group.
> 
> 1. When you or your customers have a UCM or IMP upgrade fail, what percentage 
> of failures are due to a bug vs something in the environment (user error, db 
> updates, etc)?  
> % bug:
> % not a bug:
> Yes it’s a very subjective question but that’s ok, use your judgement.
> 
> 2. When an upgrade goes smoothly with no issues, how much time do you put 
> into the planning and preparation for the upgrade (not the execution)?
> 
> Thanks,
> 
> -Ryan
> 
> ___
> 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] UCM Upgrade Poll

[Lelio Fulgenzi]

To add to this, we had a unity connection v11.5 install go awry because it 
didn't make sure the serviceability component was completed installing before 
timing out and restarting the server. The TAC had never seen anything like it 
before. No errors in the install logs. Just an entire missing component. 

Adding because I know how close the cucm and connection installs are. 


Sent from my iPhone

> On Aug 23, 2017, at 9:46 AM, Lelio Fulgenzi <le...@uoguelph.ca> wrote:
> 
> 1)
> 
> 10% bug
> 90% other
> 
> I think it's happened only once to be honest. 
> 
> 2)
> 
> Aside from service packs, we have taken an offline upgrade approach. This 
> typically involves at least one or two failed upgrades for whatever reason. 
> We then make sure we can replicate two or three successful upgrades. That 
> takes anywhere from a week to two weeks if we're able to concentrate on just 
> those tasks. But that's never the case.
> 
> Preparing for the upgrades involves reading release notes and reconciling a 
> user defined compatibility matrix. That takes a weeks or so. Dedicated, but 
> it ends up being stretched over more time.
> 
> Lelio
> 
> 
> ---
> Lelio Fulgenzi, B.A.
> Senior Analyst, Network Infrastructure
> Computing and Communications Services (CCS)
> University of Guelph
> 
> 519-824-4120 Ext 56354
> le...@uoguelph.ca
> www.uoguelph.ca/ccs
> Room 037, Animal Science and Nutrition Building
> Guelph, Ontario, N1G 2W1
> 
> 
> -Original Message-
> From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
> Ryan Ratliff (rratliff)
> Sent: Wednesday, August 23, 2017 9:38 AM
> To: cisco-voip list
> Subject: [cisco-voip] UCM Upgrade Poll
> 
> Quick 2 question poll, feel free to unicast or share your response with the 
> group.
> 
> 1. When you or your customers have a UCM or IMP upgrade fail, what percentage 
> of failures are due to a bug vs something in the environment (user error, db 
> updates, etc)?  
> % bug:
> % not a bug:
> Yes it’s a very subjective question but that’s ok, use your judgement.
> 
> 2. When an upgrade goes smoothly with no issues, how much time do you put 
> into the planning and preparation for the upgrade (not the execution)?
> 
> Thanks,
> 
> -Ryan
> 
> ___
> 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] UCM Upgrade Poll

[Ryan Huff]

I would tend to agree that the overall installation process could improve (not 
that I want to give up my ANSI art or anything). Most of the installation 
process today is merely an extension of the underlying Linux kernel. I would 
settle for more verbose feedback when errors are encountered, like dumping the 
syslog to the tmp folder on a jailed CLI that I have access to at all points 
during the install instead of the rain dance you have to do today with the 
serial port.

-RH

On Aug 23, 2017, at 4:47 PM, Anthony Holloway 
> wrote:

Wow, it's kind of cool that you're even asking.  Thanks for that.

Already I can see this is going to be a wide gap in responses. Partner vs end 
user, this customer vs that customer, this version vs that version, this 
scenario vs that one, and on, and on, and on.

1) I feel like it's always a bug (100%), in that, developers should code 
solutions that can work around most issues.  E.g., I had an upgrade fail on a 
CUCM because the ntp was 0.us.pool.ntp.org, despite 
CUCM happily syncing to it in the current version.  OR Common partition not 
having enough space, when devs could just purge old logs to make room, or 
simply make better logs to begin with (I do admit, moving to compress logs 
[TAR/GZ] was sweet)

2) This is a painful one for me, but I put in a lot of time preparing for an 
upgrade.  A large portion of the time is, in my opinion, wasted finding the 
right documentation and then trying to interpret it.  Here's a fun one: there's 
over 100 documents an Engineer needs to reference in preparation for what I 
would consider a low-medium level environment.  I've posted this before, but 
I'll post it again, I have a matrix of documents I need to reference during the 
planning and execution phase of an upgrade:

[http://cisco-voip.markmail.org/download.xqy?id=rrs3zlxbamemgodr=1]

On Wed, Aug 23, 2017 at 8:38 AM Ryan Ratliff (rratliff) 
> wrote:
Quick 2 question poll, feel free to unicast or share your response with the 
group.

1. When you or your customers have a UCM or IMP upgrade fail, what percentage 
of failures are due to a bug vs something in the environment (user error, db 
updates, etc)?
% bug:
% not a bug:
Yes it’s a very subjective question but that’s ok, use your judgement.

2. When an upgrade goes smoothly with no issues, how much time do you put into 
the planning and preparation for the upgrade (not the execution)?

Thanks,

-Ryan

___
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] UCM Upgrade Poll

[Charles Goldsmith]

But Anthony, we all know you are an over achiever!

And that's ok, it makes you one of our experts on here too...

On Wed, Aug 23, 2017 at 3:46 PM, Anthony Holloway <
avholloway+cisco-v...@gmail.com> wrote:

> Wow, it's kind of cool that you're even asking.  Thanks for that.
>
> Already I can see this is going to be a wide gap in responses. Partner vs
> end user, this customer vs that customer, this version vs that version,
> this scenario vs that one, and on, and on, and on.
>
> 1) I feel like it's always a bug (100%), in that, developers should code
> solutions that can work around most issues.  E.g., I had an upgrade fail on
> a CUCM because the ntp was 0.us.pool.ntp.org, despite CUCM happily
> syncing to it in the current version.  OR Common partition not having
> enough space, when devs could just purge old logs to make room, or simply
> make better logs to begin with (I do admit, moving to compress logs
> [TAR/GZ] was sweet)
>
> 2) This is a painful one for me, but I put in a lot of time preparing for
> an upgrade.  A large portion of the time is, in my opinion, wasted finding
> the right documentation and then trying to interpret it.  Here's a fun one:
> there's over 100 documents an Engineer needs to reference in preparation
> for what I would consider a low-medium level environment.  I've posted this
> before, but I'll post it again, I have a matrix of documents I need to
> reference during the planning and execution phase of an upgrade:
>
>
>
>
> On Wed, Aug 23, 2017 at 8:38 AM Ryan Ratliff (rratliff) <
> rratl...@cisco.com> wrote:
>
>> Quick 2 question poll, feel free to unicast or share your response with
>> the group.
>>
>> 1. When you or your customers have a UCM or IMP upgrade fail, what
>> percentage of failures are due to a bug vs something in the environment
>> (user error, db updates, etc)?
>> % bug:
>> % not a bug:
>> Yes it’s a very subjective question but that’s ok, use your judgement.
>>
>> 2. When an upgrade goes smoothly with no issues, how much time do you put
>> into the planning and preparation for the upgrade (not the execution)?
>>
>> Thanks,
>>
>> -Ryan
>>
>> ___
>> 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] UCM Upgrade Poll

[Anthony Holloway]

Wow, it's kind of cool that you're even asking.  Thanks for that.

Already I can see this is going to be a wide gap in responses. Partner vs
end user, this customer vs that customer, this version vs that version,
this scenario vs that one, and on, and on, and on.

1) I feel like it's always a bug (100%), in that, developers should code
solutions that can work around most issues.  E.g., I had an upgrade fail on
a CUCM because the ntp was 0.us.pool.ntp.org, despite CUCM happily syncing
to it in the current version.  OR Common partition not having enough space,
when devs could just purge old logs to make room, or simply make better
logs to begin with (I do admit, moving to compress logs [TAR/GZ] was sweet)

2) This is a painful one for me, but I put in a lot of time preparing for
an upgrade.  A large portion of the time is, in my opinion, wasted finding
the right documentation and then trying to interpret it.  Here's a fun one:
there's over 100 documents an Engineer needs to reference in preparation
for what I would consider a low-medium level environment.  I've posted this
before, but I'll post it again, I have a matrix of documents I need to
reference during the planning and execution phase of an upgrade:



On Wed, Aug 23, 2017 at 8:38 AM Ryan Ratliff (rratliff) 
wrote:

> Quick 2 question poll, feel free to unicast or share your response with
> the group.
>
> 1. When you or your customers have a UCM or IMP upgrade fail, what
> percentage of failures are due to a bug vs something in the environment
> (user error, db updates, etc)?
> % bug:
> % not a bug:
> Yes it’s a very subjective question but that’s ok, use your judgement.
>
> 2. When an upgrade goes smoothly with no issues, how much time do you put
> into the planning and preparation for the upgrade (not the execution)?
>
> Thanks,
>
> -Ryan
>
> ___
> 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] UCM Upgrade Poll

[Ryan Huff]

1.) Bug Poll

  Legitimate bugs (which I define as unexpected behavior in consistent with 
published Cisco documentation): 2%

  Customer Issue: 98%


2.) I usually devote 16-20 hours of planning and prepping the upgrade 
(Documentation, Visio, building the bridge if it's that kind of upgrade ... 
etc). If I have extravagant products in play like Social Miner ... the now 
defunct MediaSense ... etc, I might add a little more time but right around the 
20 hour mark is where I feel comfortable.


-Ryan



From: cisco-voip <cisco-voip-boun...@puck.nether.net> on behalf of Ryan Ratliff 
(rratliff) <rratl...@cisco.com>
Sent: Wednesday, August 23, 2017 9:37 AM
To: cisco-voip list
Subject: [cisco-voip] UCM Upgrade Poll

Quick 2 question poll, feel free to unicast or share your response with the 
group.

1. When you or your customers have a UCM or IMP upgrade fail, what percentage 
of failures are due to a bug vs something in the environment (user error, db 
updates, etc)?
% bug:
% not a bug:
Yes it’s a very subjective question but that’s ok, use your judgement.

2. When an upgrade goes smoothly with no issues, how much time do you put into 
the planning and preparation for the upgrade (not the execution)?

Thanks,

-Ryan

___
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] UCM Upgrade Poll

[Matthew Loraditch]

I've had a bug once or twice, so 10% maybe??

We have very simple installs, no clusters more than 2 servers, no user bases 
more than a 1000, and nothing more sophisticated added other than CCX or CUACA. 
We upgrade internally to the latest version first, but outside of a quick 
release notes reading and verification of compatibility it's not a lot of prep, 
maybe 30 minutes to an hour. Albeit, I usually am following along in the 
communities for the betas and various partner and CCP webcasts so I'm aware of 
any big changes/caveats ahead of time (like the end of support phone models, 
etc)

Matthew G. Loraditch – CCNP-Voice, CCNA-R, CCDA
Network Engineer
Direct Voice: 443.541.1518

Facebook | Twitter | LinkedIn | G+

-Original Message-
From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Ryan 
Ratliff (rratliff)
Sent: Wednesday, August 23, 2017 9:38 AM
To: cisco-voip list <cisco-voip@puck.nether.net>
Subject: [cisco-voip] UCM Upgrade Poll

Quick 2 question poll, feel free to unicast or share your response with the 
group.

1. When you or your customers have a UCM or IMP upgrade fail, what percentage 
of failures are due to a bug vs something in the environment (user error, db 
updates, etc)?  
% bug:
% not a bug:
Yes it’s a very subjective question but that’s ok, use your judgement.

2. When an upgrade goes smoothly with no issues, how much time do you put into 
the planning and preparation for the upgrade (not the execution)?

Thanks,

-Ryan

___
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] UCM Upgrade Poll

[Lelio Fulgenzi]

1)

10% bug
90% other

I think it's happened only once to be honest. 

2)

Aside from service packs, we have taken an offline upgrade approach. This 
typically involves at least one or two failed upgrades for whatever reason. We 
then make sure we can replicate two or three successful upgrades. That takes 
anywhere from a week to two weeks if we're able to concentrate on just those 
tasks. But that's never the case.

Preparing for the upgrades involves reading release notes and reconciling a 
user defined compatibility matrix. That takes a weeks or so. Dedicated, but it 
ends up being stretched over more time.

Lelio


---
Lelio Fulgenzi, B.A.
Senior Analyst, Network Infrastructure
Computing and Communications Services (CCS)
University of Guelph

519-824-4120 Ext 56354
le...@uoguelph.ca
www.uoguelph.ca/ccs
Room 037, Animal Science and Nutrition Building
Guelph, Ontario, N1G 2W1


-Original Message-
From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Ryan 
Ratliff (rratliff)
Sent: Wednesday, August 23, 2017 9:38 AM
To: cisco-voip list
Subject: [cisco-voip] UCM Upgrade Poll

Quick 2 question poll, feel free to unicast or share your response with the 
group.

1. When you or your customers have a UCM or IMP upgrade fail, what percentage 
of failures are due to a bug vs something in the environment (user error, db 
updates, etc)?  
% bug:
% not a bug:
Yes it’s a very subjective question but that’s ok, use your judgement.

2. When an upgrade goes smoothly with no issues, how much time do you put into 
the planning and preparation for the upgrade (not the execution)?

Thanks,

-Ryan

___
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] UCM Upgrade Poll

[Ryan Ratliff (rratliff)]

Quick 2 question poll, feel free to unicast or share your response with the 
group.

1. When you or your customers have a UCM or IMP upgrade fail, what percentage 
of failures are due to a bug vs something in the environment (user error, db 
updates, etc)?  
% bug:
% not a bug:
Yes it’s a very subjective question but that’s ok, use your judgement.

2. When an upgrade goes smoothly with no issues, how much time do you put into 
the planning and preparation for the upgrade (not the execution)?

Thanks,

-Ryan

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip