Upgrading to newer release of call manager without downtime
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?
Re: Upgrading to newer release of call manager without downtime
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
1. you will apply the upgrade to the Publisher first
2. then you will apply the upgrade to the subscriber
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.
The short answer is that you don't.... That isn't entirely true while at
the same time it kind of is, but for the most part you don't configure
the softkeys. You enable or disable them via TCL. Here is the long
answer. Be sure to read the whole thing or e...
Topology: IP Phone > Switches > Microsoft NPS setup to forward 802.1x
proxy to > ISE 2.1 patch 3 Authentication: EAP-TLS using Cisco MIC SANs
Phone Models 802.1X support? 802.1x flavor Addtl Comment EAP-MD5 EAP-TLS
Cisco 3905 Y Y N Cisco 6911 Y Y N Cisco ...
This document describe how DST changes and how time changes are
implemented in DST. Daylight Saving Time (DST) is the practice of
setting the clocks forward 1 hour from standard time during the summer
months, and back again in the fall, in order to make b...