<div dir="ltr"><div>To help in the upgrade process, I believe the SNRD also states that you can upgrade the firmware on the phones to match the new CM versions firmware to make the process move quicker when the upgrade time comes.</div>
<div> </div>
<div>Scott<br><br></div>
<div class="gmail_quote">On Thu, Jul 31, 2008 at 1:46 AM, Darren <span dir="ltr"><<a href="mailto:darren@dnsl.com">darren@dnsl.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div>I think it has to do with TFTP server order and CUCM order,</div>
<div> </div>
<div>i.e. if your CUCM's are configured as</div>
<div> </div>
<div>sub</div>
<div>pub</div>
<div> </div>
<div>and you upgrade your pub, the phones don't flip over until the sub is rebooted. (in my experience). Even if the pub reboots with new images, etc</div>
<div> </div>
<div>Watching the logs for the entries :), its hard enough staying awake when the DVD / image is extracting...</div>
<div> </div><font color="#888888">
<div>D</div></font>
<div>
<div></div>
<div class="Wj3C7c">
<div><br><br> </div>
<div><span class="gmail_quote">On 7/31/08, <b class="gmail_sendername">Kris Seraphine</b> <<a href="mailto:baryonyx5@gmail.com" target="_blank">baryonyx5@gmail.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Luckily 40s/60s upgrade much quicker.<br><br>My understanding is that after rebooting the Publisher once the CM<br>
service comes up (after installing the license) phones that use the<br>Pub for the primary CM will re-register with it and automatically<br>begin the firmware upgrade. If this is not the case, someone please<br>correct me.<br>
<br>Also, according to the 6.1.2 release notes, you don't have to wait<br>until the publisher upgrade finishes to begin the subscriber upgrade.<br>'You can begin the upgrade of the subscriber nodes after the following<br>
information displays in the log:<br><br>PRODUCT_TARGET is CCM<br>PRODUCT_NAME is Cisco Unified Communications Manager<br>PRODUCT_VERSION is <product version to which you are upgrading, such<br>as 6.1(2)> '<br><br>
<br><br>On Wed, Jul 30, 2008 at 10:14 AM, Darren <<a href="mailto:darren@dnsl.com" target="_blank">darren@dnsl.com</a>> wrote:<br>> I've done a few of these and here's the way I've done it in the past.<br>
><br>> *) If using DNS make sure reverse DNS is working correctly (sub upgrade uses<br>> this regarding the pub)<br>> *) upgrade Pub, reboot to new partition<br>> *) when this comes backup it doesn't become properly active (depending on<br>
> config of cluster) so normally the phones will stay with the existing<br>> cluster (again depending on config of cluster).<br>> *) upgrade subscriber and reboot.<br>><br>> Phones will reboot, in my scenario this never took more than 20 minutes,<br>
> with 7940's and 60's. From 200 - 400 handsets.<br>><br>> To do each server takes approximately 2 hours each. I was under the<br>> impression you had to do it in this order to get the publisher database in a<br>
> good condition for the subscriber database to use, but I could be wrong<br>> (anybody able to clarify this).<br>><br>> D<br>><br>><br>><br>><br>> On Wed, Jul 30, 2008 at 11:01 PM, <<a href="mailto:keli@carocomp.ro" target="_blank">keli@carocomp.ro</a>> wrote:<br>
>><br>>> There are close to 1000 phones, a mix of 7940, 7960 and CIPC soft-phones,<br>>> load-balanced across the two servers (so some have the sub as primary, while<br>>> others have the pub as primary in their CCM group)<br>
>><br>>> Also, since the servers are in a datacenter, and the phones in several<br>>> locations in a metropolitan area, I'm not exactly sure of the "distances" of<br>>> each location ...<br>
>><br>>> Anyway, the good news for me seems to be that the 7940/60 phones have a<br>>> much smaller firmware :)<br>>><br>>> thanks,<br>>> Zoltan<br>>><br>>> Quoting Kris Seraphine <<a href="mailto:baryonyx5@gmail.com" target="_blank">baryonyx5@gmail.com</a>>:<br>
>><br>>>> Are all the phones registered with the same box? If so, your downtime<br>>>> should be limited to the time it takes to upgrade the phone firmware.<br>>>> The SRND has a section on how to calculate this. I just upgraded 25<br>
>>> 7941s to 8.3.5 last night over a T1 line and it took 24 minutes (from<br>>>> start until all phone were registered again). This was with peer<br>>>> firmware sharing enabled.<br>>>><br>
>>> I'd imagine you'd want to install the license after rebooting the<br>>>> publisher but before rebooting the sub. The CM service won't start<br>>>> until the license is installed.<br>
>>><br>>>> On Wed, Jul 30, 2008 at 8:49 AM, Kelemen Zoltan <<a href="mailto:keli@carocomp.ro" target="_blank">keli@carocomp.ro</a>> wrote:<br>>>>><br>>>>> Hi,<br>>>>><br>
>>>> I'm going to upgrade a cluster of two CUCM 5.1.2 servers (both MCS7845)<br>>>>> from<br>>>>> 5.1.2 to 6.1 release.<br>>>>><br>>>>> However, the customer is keen on knowing expected service outage times,<br>
>>>> and<br>>>>> the duration of the whole operation in itself. Even if they do not<br>>>>> expect<br>>>>> exact timeframes, telling them "it will take a lot" just won't do :-)<br>
>>>><br>>>>> So can anyone give me an idea, of how much time would it take to upgrade<br>>>>> this cluster and of this, approximately how much would they be without<br>>>>> service?<br>
>>>><br>>>>> Especially, since, as far as I understand, upgrading in itself does not<br>>>>> mean<br>>>>> interruption is service, since I'm working on an inactive partition.<br>
>>>><br>>>>> Also, is this planned order correct (basically based off SRND):<br>>>>> - upgrade first node, don't reboot<br>>>>> - upgrade second node (there's only one), don't reboot<br>
>>>> - reboot first node with switching versions<br>>>>> - reboot second node with switching the version<br>>>>><br>>>>> the Feature licenses for the v6 should be uploaded before the upgrade<br>
>>>> process, or after the first node reboot?<br>>>>><br>>>>> thanks,<br>>>>> Zoltan<br>>>>> _______________________________________________<br>>>>> cisco-voip mailing list<br>
>>>> <a href="mailto:cisco-voip@puck.nether.net" target="_blank">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>>>><br>>>><br>>>><br>>>> --<br>>>> kris seraphine<br>>>><br>>><br>>><br>>><br>>> ----------------------------------------------------------------<br>
>> This message was sent using IMP, the Internet Messaging Program.<br>>><br>>> _______________________________________________<br>>> cisco-voip mailing list<br>>> <a href="mailto:cisco-voip@puck.nether.net" target="_blank">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>><br><br><br><br>--<br>kris seraphine<br></blockquote></div><br>
</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>