Upgrades are a fact of life for network rock stars. Whether we are patching bugs or adding new features to our systems, the installation of software never seems to end. If you are a Cisco voice rock star, you all too often find yourself upgrading to newer releases of Cisco Unified Communications Manager (CUCM) to support new devices like the Cius or fix show stopping bugs like the 180-day uptime lockup. However, if you are a user of CUCM 8.x and you’re trying to move to 8.6, you’ve probably had a couple of head scratching moments so far.
If you’ve popped a freshly burned 8.6(1) ISO into your DVD drive or copied it via SFTP, you kicked off you installation and likely saw the following error message:
09/18/2011 19:31:48 refresh_upgrade|********** Upgrade Failed **********|<LVL::Info> 09/18/2011 19:31:48 refresh_upgrade|*** Please install the Refresh Upgrade COP, and reattempt the upgrade ***|<LVL::Info> 09/18/2011 19:31:48 refresh_upgrade|************************************|<LVL::Info>
Huh? What’s a refresh upgrade? Why isn’t this ISO file working? Well, it turns out Cisco needs you to take an additional step first.
CUCM runs on an operating system. Up until version 5, that was Windows 2000 with some hardening and customizations. Cisco eventually ported CallManager 4.3 to Windows Server 2003, but in the end the decision was made to move to an appliance-based OS that utilized Linux. The Telephony OS in CUCM 5.x was new for those used to working in Windows but somewhat familiar to those that have seen Linux before, even if the login shell looked nothing like bash. Cisco provides patches for the OS with every release of CUCM software and the user never knows what’s going on because of the way the system installs the patches transparently. However, much like the shift from Windows 2000 to Windows 2003, software eventually reaches the end of its life. Development stops on the old version and it’s time to move to the new one. Such is the case in CUCM. With version 8.6, Cisco has moved away from an OS platform based on Redhat Enterprise Linux (RHEL) 4 and upgraded the underlying OS to RHEL 5. This is good news that allows the system to stay current and support a larger variety of hardware. The bad news is that the upgrade of the OS can be a bit destructive. This is part of the reason for the extra steps in moving to CUCM 8.6
Firstly, Cisco wants you to install a special Cisco Options Package (COP) file on 8.5(1) systems. This file is ciscocm.refresh_upgrade_v1.0.cop.sgn. The 8.6 installer checks for the presence of this file and won’t kick off unless it’s present. It needs to be installed on every server in the cluster. It’s also going to reboot the server after installation. As near as I can tell, it makes some changes to the Tomcat service on the server as well as adding two new fields to the Install/Upgrade window:
Notice the new options for email. This allows the server to send you an email whenever the upgrade is completed. Probably a long overdue option that comes in handy for those of us that spend more than a few stress-filled moments clicking the Refresh buttons on our web browsers waiting for CUCM to come back to life after an upgrade. There’s another reason for putting this email field in here now, though.
It turns out that when you upgrade from 8.5 to 8.6, its going to take a while. Quite a while, in fact. The system is going to reboot no less than twice, perhaps even three times. Considering that a CUCM reboot can take 15-20 minutes to complete each time during an upgrade, you’re looking at nearly an hour of rebooting time under certain circumstances. During the upgrade, CUCM is going to do things in 3 phases:
Phase 1: Export all the pertinent CUCM data to a safe partition
Phase 2: Reboot and install RHEL 5, then reboot and install the CUCM applications
Phase 3: Import all the data from the export partition
On the 7825H3 MCS server, there isn’t enough hard drive space to contain the safe partition during the reformat and installation of CUCM 8.6. In that case, you’re going to need to plug a 16 GB USB drive into the system to serve as a target for the data export. If you’re trying to upgrade a CUCM Business Edition system on a 7828H3 server, you better bust out the credit card because you’re going to need a 128 GB USB drive to hold all the CUCMBE data during the upgrade. The IBM servers aren’t affected by this little caveat, as I’ve done the 8.6 refresh upgrade on a 7825I4 and not had any issues. Be sure to leave the USB drives plugged in the whole time the system is upgrading. Also, whatever is on the drive is going to be overwritten without warning, so be sure it’s blank before you start.
After you’ve completed the whole installation with all the reboots, you’re going to have a fresh new system with CUCM 8.6 to support all kinds of wonderful things, like finally being able to use Google Chrome to administer things.
I kicked off an upgrade to 8.6 without reading the release notes or documentation. Thankfully Cisco prevented me from screwing things up big time by halting the installation with the above error message. The more I dug into things, the more interesting it was. It also took me two hours to finish things up with many reboots and even more nail biting (Fun fact: I was doing the upgrade during Packet Pushers Show 56, which is one of the reasons why I was quiet – I was trying not to scream at my CUCM server). However, I think I could have avoided some pain and stress if I’d just read the docs first or even searched for refresh upgrade before I got started.