Call Manager upgrade without upgrading phone FW

[teekow]

I would like to apply a service update on my cluster to solve a specific issue that is a known bug with our existing 9.1.1(a). I will be upgrading to 9.1(2)SU2a and a newer phone firmware will be on the tftp servers post upgrade. I would like to prevent the phones from upgrading if possible. I have 1 publisher node, 2 sub nodes for TFTP, and 2 sub nodes for registering phones. My idea is to switch versions on the publisher and TFTP nodes followed by manually replacing the phone firmware files on the TFTP server back to the old files. After that, I will switch versions on the phone registration nodes which is normally where the phones would upgrade firmware. Since I had manually replaced the fw files back to what they were pre-upgrade I am thinking the phones will go through a reboot but they won't upgrade.

Just trying to figure out if I am on the right track and whether or not my idea is valid. If there is a better way to accomplish please let me know and thanks.
Rob

 

[whykap]

After you upgrade the publisher, go to default device firmware and put the old versions back.
Then you can upgrade the rest of the servers and reboot the phones.
The key is not to reset phones before you do that.
Make sure you go to the default firmware before you upgrade and copy the existing values so you can put them back after the upgrade.

 

[teekow]

thanks for the feedback......can you offer your opinion on my actual downtime and tell me if I am understanding this properly? I will upgrade the inactive partition on all of the servers starting with the publisher choosing the option not to reboot at the end for all of the servers. Then I will switch versions on the publisher and wait until that comes back online. I will then change the default fw back to where it was pre-upgrade followed by switching versions on the 2 TFTP servers and checking the default fw on those servers to confirm it matches the pub. At this point there has been no downtime in my scenario. Once I switch versions on my sub that registers everything my thought is that the phones will register to the backup sub for registration. Active calls will be preserved and the phones will reset only taking <10 sec. After registration Sub1 is back online I will switch versions on registration Sub 2 and the same phone reset will occur back to Sub 1. I am anticipating negligent downtime only to reflect 2 resets of the phones while they re-register. Let me know if I am thinking this through properly and thanks very much.
Rob

 

[gnrslash4life]

Few things.

Once you reboot the Pub..consider this down time. You now have a cluster with different versions. Reboot the subs at once if in the same physical location or by location. But regardless you want to do it asap. You will have downtime. I would suggest figuring 2 hours. Shouldn't be that long but its a safe number.

Certifications:
A+
Network+
CCENT
CCNA Voice

 

[teekow]

I understand it is a maint window but that really is different than user impacting down time. Why would my phones go down when they are not registered to the publisher? I get the idea that you can't leave different versions on pub and sub. I am just trying to determine at what point users will actually experience an outage. I don't believe it is when the publisher switches version. Thanks so much for the information, I will definitely keep it in mind.
Rob

 

[HmmG3]

When you upgrade the pub and after it reboots, the phones should not be affected. They will continue to function normally (assuming all of them are registered just to the sub). In fact they will continue to remain normal through the sub upgrade. Only once the sub needs to be rebooted after the upgrade will the phones failover to the pub will you experience a disruption. That is when they will most likely perform an upgrade as well if you left didn't change the default firmware version after the pub upgrade. Once the sub comes back online, they will do a graceful fallback. This means if they are in use, they will stay registered to the pub until the call ends. If they are idle, they will go ahead and fallback.

My normal practice when doing a major CUCM upgrade is to install the newer firmware in advance. This allows me to more precisely control the upgrade process by selectively rebooting phones after the firmware is installed on the pub/TFTP (instead of having all phones go down at once for an upgrade). Then when I do the CUCM upgrade later, not having to deal with the phones being upgraded is one less thing to worry about and keeps the service disruption shorter.

When I've done small patch upgrades or device packs where the default firmware gets upgraded but I don't want the phones to change, I always update the default fields after the pub reboots. Only once I've done that do I move on to the sub upgrades. This prevents the phones from upgrading and keeps their downtime to being very short as it's just a quick failover when the sub reboots.

 

[hanluc6933]

To add onto what has previously been said... if you're looking for a general base time when restarting and updating device firmwares...

When I restarted the subscriber 900 devices completed the failover to the publisher. At this time the devices pulled the new firmwares (Intentionally didn't change the device defaults). For 900 devices the process took just over 40 minutes including, server restart, device updates and the migration back to the subscriber.

~Han



The great use of life is to spend it for something that outlasts it. ~William James