Recently, I got the pleasure of having a rather nail-biting experience upgrading from Presence 8.5 to 8.6(4). I will recount my joyful experience so all of you can point, laugh, and then confidently take on your own upgrade.
If you are planning an upgrade to CUPS 8.6(4) let me first say don’t even consider this seemingly minor upgrade without reading Tom’s post on the subject first. Go here http://networkingnerd.net/2012/07/05/upgrading-to-cisco-unified-presence-server-8-64-caveat-jabber and heed Tom’s excellent warnings and advice.
I just have a few things to add to the topic given my recent experience. One, the required .cop file acts a bit flaky* when upgrading from the version I was on, 8.5.4.10000-16, to 8.6(4). The first server I installed it on got a “successfully installed” message immediately followed by a “.cop not found” error message. Always a good way to start, right?
Looked something like this:
08/29/2012 12:19:38 Install of ciscocm.cup.refresh_upgrade_v1.01.cop completed SUCCESSFULLY
——————————————————————–
(28609) Wed Aug 29 12:19:46 CDT 2012
install option
(28609) Wed Aug 29 12:19:46 CDT 2012
ERROR: Option file /common/download//ciscocm.cup.refresh_upgrade_v1.01.cop not found.
I promptly ssh’ed to the server, did a #show version active and confirmed the .cop was indeed hanging out where it was supposed to be.
Loading the .cop on the secondary server didn’t produce the same error as before after the “successfully installed” message, BUT this time the installation wouldn’t stop running.
I gave it about an hour, knowing the install on the primary only lasted ten minutes. Then, I took a deep breath and rebooted the server. When it came back up, the .cop file was definitely there and the services all came up. I decided now was a good time to start breathing again.
Now came the actual installation of the upgrade file on the primary server. This took FOREVER. Okay, really about 3 hours, but it felt much longer. During this time the server undergoes a reboot and progress for the upgrade must be monitored via the console. Eventually, I got the longed for “installation successful” message and the server went down for what I thought was the final reboot.
Now, you should know that during these voice server upgrades, I never choose the option to reboot and switch automatically to the new version, so imagine my surprise when the server came up with the 8.6 version active instead of my old, comfortable 8.5 version.
Confused at the server’s puzzling disregard for my authority, I started digging around to find out why this brazen box had disregarded a direct order. As I’m looking for clues, I get a “you can’t handle the truth” message along with a “database connection failed” warning. Okay, really only the latter, but my stress level is escalating rapidly and somebody’s about to yell “code red.” I then peek over at the console and see that the system is shutting down. Oh, okay. Sure. Why not. I obviously have no control over this process any how…
Now as you might have already guessed, the server was actually rebooting, AGAIN, and the 8.5 version once again is the operating system of choice. Okay, I wish I had known to expect that…
So cue the installation on the secondary server, which *almost* goes off without a hitch. Apparently the so-called “non-bootable” ISO I downloaded from CCO is, in fact, very bootable. And guess whose virtual machine was unknowingly set to boot to DVD first. Yep, lucky me!
Reboot time came around during the upgrade process and instead of a smooth continuation of the upgrade process, I get a console screen full of “would you like to do a media check? how about a nice game of chess?”
Easy fix here, just went into VMWare management of the server, told the server to boot to BIOS, changed the boot order, crossed fingers the installation would overlook this infraction, and allowed the server to boot again. Fortunately the installation was feeling supremely guilty for stressing me out and decided to let this one slide. At least that’s how I took it.
The last bump I hit on this upgrade happened when switching versions on the secondary. The primary server switch versions went picture perfect. The secondary server, not so much. I landed on this during the version switch:
starting cupOnL2BootInitd
And I stayed there. One hour later, still there. And three hours past that, well, you get the idea…
A Google search led me to bug ID CSCto83389 which, to paraphrase, says something like, hey, this file is hung, TAC can fix it from the command line, give them a call.
It’s at this point I decide to call it a night and start fresh and much less angsty in the morning.
Fortunately I awoke to what turned out to be OMG Miracle Thursday.** When I logged into the server to get my serial number for TAC, I noticed the secondary server was no longer in version limbo-land, but had completed the switch over to version 8.6.
The services were running and all was right with the world. There were also birds singing and a chorus of angels outside my cubicle window.***
Published 09/03/3012
*flaky – you know, the technical term for when things are wonky…
**also known as you-are-one-lucky-sob-day and holy-crap-buy-a-lottery-ticket-day
***those may have been window washers wearing white jumpsuits…
Amy Engineer 