<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>
<div>D</div>
<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">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">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">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">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">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">cisco-voip@puck.nether.net</a><br>>>>> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip">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">cisco-voip@puck.nether.net</a><br>
>> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>><br>><br><br><br><br>--<br>kris seraphine<br></blockquote></div><br>