If you’ve been in the Cisco voice game for more than a second, you’ve probably done a Call Manager upgrade or two. In my case, I lost count around version 4.1 to 4.3. My record for the longest upgrade that I was a part of is 72 hours…straight! It was painful but such was life back in those days.
With the advent of virtualized Cisco voice and all of its associated parts the upgrades have definitely improved, but that does not mean that the gotchas aren’t still lurking.
For one of my current customer projects I am upgrading a virtualized 9.x environment to 11.x. Unity Connection was upgraded first using CLI. CUC luckily doesn’t have a whole lot of gotchas assuming the engineer that built it originally used an OVA template and followed the correct steps. All you need to do is apply the new “keys” COP file (ciscocm.version3-keys.cop.sgn) and you are good to go. Maybe it isn’t quite that easy, but you get the picture. Communications Manager (Call Manager) is a far different animal. For the sake of automation, I’m doing the CM upgrade using Prime Collaboration Deployment (PCD). PCD is a separate application server that comes with your upgrade order on Cisco’s Product Upgrade Tool (PUT). PCD basically allows you to take a CM cluster (including IM&Presence) and script the upgrade so that you can basically click once and wait. If only it were that easy…
There are a couple gotchas that I’ve learned the hard way. I’ll list them below, hopefully they can help you out during your next upgrade.
- Licensing. If you are going to do an upgrade, do your homework. I could write an entire post on licensing but for a 9.x to 11.x upgrade it really just involves doing clean up. If you are getting that ugly little licensing warning from Cisco when you log into your system, clean it up before attempting to upgrade, you’ll save yourself from a lot of pain later.
- Disk Space. I get it, hard drive space is cheap, but OVAs are not future proof. The original mid-size build OVA for CM 9.x specified an 80 gig virtual drive. The 80 gig drive model is not not supported by fresh 11.x installs. What bites engineers in the ass is a pesky little storage location known as the common partition. When the 11.x upgrade script first verifies that an upgrade is possible, it checks the amount space available in that common partition, if less than 25 gigs space is available the upgrade will fail. There is an excellent Cisco Support Forums post about this failure here. So what do you do if the above scenario is true?
There are 3 options…
- You can go into your server’s TFTP directory and manually remove old crap that you don’t need. If you happen to remove crap that you do need, bad things WILL happen, so keep that in mind….
- You can apply the following COP file ciscocm.free_common_space_v1.3.k3.cop.sgn. This little beauty will remove any software tied to the inactive partition of the system which may include software tied to the common partition, thus giving you your required space. This is a really cool idea/theory, but I’ve had mixed results.
- This is the scariest sounding one, but its actually not that bad. There is a second COP file that you can run. The ciscocm.vmware-disk-size-reallocation-1.0.cop.sgn; This file will allow you to resize your virtual disk in VMWare ESXi and make CM ok with it (I tend to expand 80 gig disks to 160 as long as the physical systems allow it). **Changing the size of the disk without the COP file basically guarantees you a rebuild from scratch and possibly a resume` generating event.** As I said, its not that bad, but there is a catch. In a couple of different cases, your results may vary.
1. If your CM system is running on a snapshot within ESXi, your virtual disk size adjustment option will be grayed out, this will inevitably cause you to panic and wonder if a PCD migration is your only option, its not. You can actually delete the snap shot and once you do that you should be able to change your disk space. Once you do this, restart your VM and let it go through its process. It will reboot 2 times during the start-up process as it expands the disk in the “BIOS” and then in the initial CM boot process If you’ve done it correctly you’ll see your partitions aligned and your new disk size in both the CLI and web console.
2. In some cases the allocation of your virtual disk may be as large as the blocks with in the disk controller will allow it to be. If this is the case, you have two options. Option 1 (see option 1 above). Options 2, migrate instead of upgrade using PCD. It will take more time but you and/or your customer’s data should be safe and back where it belongs.
Whew… that was a long post. I hope it helps someone. For those of you new to upgrades, you’re lucky, they keep getting easier. If you have questions, leave a comment and we can have a discussion. Thanks for reading!
-Justin
Justin On VOIP (and more) 
Hello,
How long should it take with PCD and all necessary files etc… To do an Upgrade/Update of CUCM 9.x to 11.x with Publisher and Subscriber, and also do Unity with same for redundancy (Approximate of course). Have been tasked with putting together a SOW for Project and believe minimum is 3-4 hours for each node, but wanted to check with someone with experience.
Hi Paul,
3-4 hours is not a bad estimate but I think 2-3 is a better one. The biggest issue with upgrading CUCM from 8.x/9.x to 11.x is that in several cases hard disk sizes for the older versions of CUCM were sized too small i.e. 80Gigs instead of 160Gigs that we are used to today. As I cover in the post, the fix for this issue is not terrible but it does take time. If you can get out ahead of the issue, which is pretty easy to spot, and get a plan put together you can correct the problems before kicking off the PCD job and having to troubleshoot a failure. Because Unity can run version independent of CUCM consider a two night approach where you upgrade Unity the first night and then upgrade CUCM the next night. While PCD supports Unity Connection upgrades, I’ve been told that it does not automatically switch versions in PCD 11.5.3 (I’ve yet to verify this for myself). Personally, I’ve always done my Unity Connection upgrades manually from the CLI as they tend to be much more simple and quick than a CUCM job.