Typically a CUCM upgrade will include a change in the firmware. Unless you modify the Device Defaults after the upgrade your phones will receive the new firmware load information when they pull the configuration file from the TFTP server. If the new firmware load version does not match the running version on the phone, then the phone will upgrade the firmware before registering to the cluster. Depending on the size of your cluster, the size of the firmware, the distribution of phones across the LAN/WAN, etc. that could lead to an extended outage when doing the upgrade.
We recommend that you consider one of the following approaches.
First, determine if the existing firmware is compatible with the new CUCM version and features. If so, then if you are not experiencing issues with the new firmware there is no need to upgrade. In this instance, when you do your upgrade you will want to modify the Device Defaults before you reset the phones.
Second option. It is more likely that you will find you want to upgrade the firmware of the phones (and even more likely you will want something later than what comes with the CUCM upgrade by default). In these cases you will want to pick firmware that is compatible with the current release of CUCM and the target release. Then schedule a change window in advance of your CUCM upgrade where you upgrade the firmware on the phones. It is definitely a good idea to separate phone firmware upgrade from CUCM upgrades. Primarily because you will already have enough to deal with and you want to minimize overall risk and exposure to faults. Divide and conquer being the mantra.
In both of these options, you may find that you need to either trick the phones into not upgrading firmware or block access. Blocking access can take the form of using a network ACL that blocks access to your TFTP servers. It can also take the form of disabling/stopping the TFTP services on the TFTP servers. This really becomes an issue if the server that is your TFTP host and your publisher also is the primary call processing agent for phones. One approach that works for me is to use BAT to force the phones to use a specific firmware version (the one they are already running). This way, when you upgrade the CUCM the phones will disregard the device defaults and use their locally programmed firmware version instead. Then, once the dust settles on your upgrade, use BAT to remove the device-specific firmware load ID. This puts you back to the status quo of using the Device Defaults which is operationally preferred.
HTH.
Regards,
Bill
Please remember to rate helpful posts.
