[cisco-voip] CUCM Cluster SU install + device Package
Anthony Holloway
avholloway+cisco-voip at gmail.com
Tue Aug 30 12:53:50 EDT 2016
"...we can easily revert to the pre-maint defaults..."
I would do it the BAT export way. It's easier than messing with HTML, and
avoids copy/paste errors.
On Sun, Aug 28, 2016 at 10:45 AM, Mehtab Shinwari <mshinwari at fidelus.com>
wrote:
> To add to what Ryan suggested what we do is:
>
>
>
> 1) Get the Device count summary to identify what devices we have
> (Navigate to Cisco Unified Reporting à Unified CM device Counts summary)
>
> 2) We save an HTML copy of the device defaults pre device pack
> installation
>
>
>
> This way even if (and in most cases it does) the device pack installation
> updates the firmware we can easily revert to the pre-maint defaults by
> identifying the devices we use (#1) and easily copying the original
> firmware version from an offline copy (#2).
>
>
>
> Regards
>
>
>
> *Mehtab Shinwari* | CCNP-V/RS, VCP-DCV
> Senior Support Engineer – Managed Services Shift Supervisor
> www.fidelus.com
>
>
>
> --------end attach--------
>
>
>
> *From:* cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] *On Behalf
> Of *Jorge L. Rodriguez Aguila
> *Sent:* Sunday, August 28, 2016 10:44 AM
> *To:* Ryan Huff <ryanhuff at outlook.com>
> *Cc:* Cisco-Voip <cisco-voip at puck.nether.net>
> *Subject:* Re: [cisco-voip] CUCM Cluster SU install + device Package
>
>
>
> Your logic is completely sound, I will open a case with TAC and see what
> they come up with and also have recourse for assistance should this go
> sideways
>
> Jorge Rodríguez, CCNP, CCNP-V
>
> Senior Voice/Data Consultant
>
> Netxar Technologies
>
> 7876888530
>
> jorge.rodriguez at netxar.com
>
>
> On Aug 28, 2016, at 10:27 AM, Ryan Huff <ryanhuff at outlook.com> wrote:
>
> The primary reason for a cluster reboot after a device package install is
> to refresh the RIS Data Collector, TFTP, Tomacat, A Cisco DB (and one other
> ... I think) services; which is needed when the device package includes the
> installation of device model support not previously supported. If the
> device package does not include additional model support not previously
> supported; it's usually not much more than a collection of firmware that
> would just require a TFTP refresh in the cluster (although, either way, it
> does update the default load values under *Device->Device
> Settings->Device Defaults*).
>
>
>
> *If you are not prepared to push the new loads to all devices; I suggest a
> BAT export of the Device Defaults BEFORE installing the device pack and
> then a BAT import of the same Device Defaults export AFTER the device pack
> is installed, BUT, before any cluster reboots or TFTP service refreshes
> (you can always record or BAT export the references of all the new loads
> after you install the device pack but before you restore them to the
> previous values).*
>
>
>
> The device package, *cmterm-devicepack10.5.2.14082-1.cop.sgn* adds device
> support for the Cisco Wireless IP Phone 8821 (http://www.cisco.com/web/
> software/282074299/134616/cmterm-devicepack10.5.2_14082-
> 1_Release_Notes.pdf). When you install the device package, any changes to
> Informix for the new model support are made during the device package is
> installation; the cluster restart is to ensure all required service
> refreshes are complete cluster-wide.
>
>
>
> In *theory* (I say theory because I simply have never attempted this),
> you could complete the device pack install (on all cluster nodes) and then
> install 10.5(2)SU3a on the cluster nodes and do a single reboot. However,
> in full disclosure, I have never tried it that way .... the logic is sound
> though and I have every reason to think it would work fine.
>
>
>
> Personally, I am averse to doing *anything* that I think is even remotely
> risky in a production environment without testing. If this were my deal
> (and I had the extra time); I'd spin something up in a lab and just 'try
> it' first to see if anything blows up. Using dCloud may be an option too
> if you have a *really* good connection (uploading the uc update and
> device package files could prove cumbersome otherwise).
>
>
>
> Beyond that, never fail alone ... get a TAC case open; if TAC says it will
> work ... GREAT, if something does go wonky you have recourse. If TAC says
> no ... there is your answer AND, it gives you business justification for
> needing two (2) separate cluster reboots.
>
>
>
> Thanks,
>
>
>
> = Ryan =
>
>
> ------------------------------
>
> *From:* cisco-voip <cisco-voip-bounces at puck.nether.net> on behalf of
> Jorge L. Rodriguez Aguila <jorge.rodriguez at netxar.com>
> *Sent:* Sunday, August 28, 2016 9:35 AM
> *To:* Cisco-Voip
> *Subject:* [cisco-voip] CUCM Cluster SU install + device Package
>
>
>
> We are going to be performing an update to the latest SU on a CUCM 10.5
> cluster soon. The latest Patch was released on Jun 2016 while the latest
> device package is from August. My main question is, Can I run the Device
> Package Installer, not reboot the cluster, perform update and do the switch
> version? Will I have do do them separately? I’m trying to avoid having to
> do two cluster reboots since this is a 24/7 Operation and we scheduled a
> six hour window for the upgrade on a 5 CUCM/ 2 CUC Cluster
>
>
>
>
>
>
>
> Jorge Rodriguez, CCNP, CCNP-V
>
> Senior Voice/Data Network Consultant
>
> Netxar Technologies, a Digicel Company
>
> Cel 7876888530
>
> Office 7877650058
>
> jorge.rodriguez at netxar.com
>
>
>
>
>
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160830/1ba0c068/attachment.html>
More information about the cisco-voip
mailing list