<div dir="ltr"><div><div><div><div>Ryan,<br><br></div>I perform the task you describe often and depending on the customer, in different ways.....<br><br></div>I would not suggest only installing a device pack on some servers.. Device packs are meant to be installed on all nodes of the cluster. Its not a best practice, its a great practice. All nodes get all need cop files...<br><br></div>The largest client I work with now we started the implementation using lessons learned from past needs like this. The phone load is hard set at each phone vs. leaning on the device defaults. This method works great. It gives me ultimate granularity when it comes to who gets what load and when.<br><br></div><div>If the client wasn't deployed this way, its easy to get there. Bulk update before you need to.<br><br></div><div>If this method doesn't flip your switch, another method I've used in the past is to keep the device defaults page /ccmadmin page open during the device pack install on the publisher. I usually run the cop file installs from ssh. (faster and thinner) Once the device pack has run its course, the device defaults page has not timed out yet. Then you comitt your pre-device-pack parameters back to the db by hitting the save button. (can also export the device defaults before the device pack install, then import back in post device pack install)<br><br></div><div>The last 2 methods will work only if a phone doesnt reset/reboot after the device pack has been installed but before you've set the device defaults back. the first method.... it wont matter...<br><br></div><div>If all else fails... force your phones into fallback or keep them from registering to the server by an ACL.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 3, 2015 at 2:31 PM, Ryan Huff <span dir="ltr"><<a href="mailto:ryanhuff@outlook.com" target="_blank">ryanhuff@outlook.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div dir="ltr">Correct, ordinarily that would be what I would do as well. In this case though, I am trying to avoid upgrading the firmware on anything, other than the devices I am trying to get support for.<br><br>Thanks,<br><br>Ryan<br><br><div><hr>Date: Sat, 3 Jan 2015 14:20:43 -0600<br>From: <a href="mailto:brez@brezworks.com" target="_blank">brez@brezworks.com</a><br>To: <a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>Subject: Re: [cisco-voip] Device pack installation methodology question<div><div class="h5"><br><br>
<div>On 1/3/2015 2:11 PM, Ryan Huff wrote:<br>
</div>
<blockquote>
<div dir="ltr">I need to install a device pack on a 2 node 9.1(2)
CCM cluster to get support for some 88xx phones but I do not
want to update the loads for anything else.<br>
<br>
The approach I am going to use is:<br>
<br>
Drop the publisher out of the CM Group, forcing all phones to
the subscriber. Install the device pack on the publisher and
reboot the publisher. Once the publisher is backup, set all the
device defaults back to what I want them to be then add the
publisher back to the CM Group. Then drop the subscriber from
the CM Group forcing all the phones on the publisher and start
the install process over for the subscriber. Once everything is
back up add the subscriber back to the CM Group.<br>
<br>
Does that sound reasonable or is there an easier way?<br>
</div>
</blockquote>
<br>
Any time I've needed device support I just install it on all the
nodes then reboot them one at a time during a maintenance window.
As long as both nodes are running call processing, they'll fail over
when the node reboots. Not sure about on 9.X, but on 10.X this just
shows as a blip on the phones of them reregistering, not a full
reboot. Obviously if you install new software for those phones,
they'll upgrade software when they reboot.<br>
<br>
Jeremy "TheBrez" Bresley<br>
<a href="mailto:brez@brezworks.com" target="_blank">brez@brezworks.com</a><br>
<br></div></div>_______________________________________________
cisco-voip mailing list
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a></div> </div></div>
<br>_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br></blockquote></div><br></div>