Upgrading to newer release of call manager without downtime

[latintrpt]

I'm looking to upgrade from 7.1.3 to a newer version.

The reason for this is to support the new 9971 phone as it doesn't appear in my list of phones.

I currently have a Publisher and a subscriber.  My phones are registered to the Publisher at the moment.  I'm looking for a way to upgrade without having my phones upgrade as soon as the upgrade is completed.  I work in a hosptial and to have all the phones upgrade at once, is unacceptable.  Any ideas as to what I can do to bypass this situation?

Thanks

[William Bell]

Sure. We do this all of the time. The general procedure would be:

Assumptions (just so we have something to talk to):

Publisher: CM service, TFTP service

Subscriber: CM service, TFTP service

- Upgrading to something like 7.1(3b)su2 as opposed to device package update.

- your existing phone firmware is compatible with the new version of CUCM software you plan to load

General Process:

1. you will apply the upgrade to the Publisher first

2. then you will apply the upgrade to the subscriber

Procedure:

1. Go to Device>Settings>Device Defaults and capture the current firmware releases

2. Stop and disable TFTP service on the publisher; stop the TFTP service on the subscriber

3. Load the install file

4. Reboot the publisher

5. Go to Device>Settings>Device Defaults and modify the firmware releases to what you want them to run (i.e. change them back to the configs you had in item #1)

6. Activate and enable the TFTP service on the publisher

7. Load the install files

8. Reboot the subscriber

9. Double check the Device Defaults

The above procedures is for a SR or minor release update. The general consideration being that a snapshot of the db is replicated to the B-partition when you do the install. The reason you deactivate the TFTP service is to keep it from coming on line when the system is booting and avoiding accidental TFTP downloads. If you are doing a COP device firmware or device package install, you may not need to reboot the entire system (though device packages usually say to reboot the system).

Basically what you want to do is stop any TFTP transactions during the upgrade process. Giving you enough time to modify the Device Defaults to use the firmware that you want them to use. Then open up TFTP transactions.

Another approach would be use ACLs on the routers in front of your CUCM nodes to block TFTP completely.

A third approach is to use BAT and force/hardcode the firmware files on every phone. These values are not overwritten by any device package or CM upgrade (even if the defaults are updated, the device level trumps the system default).

A final approach would be to schedule your firmware changes ahead of your CUCM changes so that they are already on the level of firmware that is included with the CUCM upgrade. I hardly ever have the luxury of doing this. I always seem to need a firmware release that is different than what is built into the CUCM upgrade package.

HTH.

Regards,

Bill