You may have read in my previous posts that I’m currently working on some upgrades. A part of this overall upgrade plan includes upgrading UCCX from 11 to 11.5. This is due to ESXi and CUCM compatibilities.
Let’s jump right in to the upgrade, shall we?
Note that once you start this upgrade, do not make any changes to UCCX until you are complete. Also, do not perform this upgrade during normal business hours, plan it for after-hours only, it is service affecting. While it may seem like installing the file would be harmless, you never know what doing that could cause!
- First we want to confirm our active version. Issue the command show version active to do this. You will see our current version of UCCX displayed.
- Now let’s issue the command utils system upgrade status to confirm we are good to upgrade.
- Once we see that we are good to upgrade, lets issue utils system upgrade initiate. This command is a four step process. (See below the image for the details)
- First we will tell UCCX how we are retrieving the file. I am using SFTP, so I issue the command number 1.
- Once I’ve done this, I need to give it the SFTP information including our directory, which is just the root folder, so I put in “/”, the IP address of our SFTP server, then the username and password for our SFTP account. Refer to my former post about setting up an SFTP server if you need assistance with this part.
- It will ask if you want to enter SMTP host server information, we will just ignore that because we are going to hang out for the upgrade.
- Finally, once it connects to our SFTP server, it will look for valid upgrade files and ask us which one to load. We only have one valid upgrade file, so I issued the command number 1 and hit enter. NOTE – Once you hit this, it will probably take 20 minutes, or longer depending on your network connection, to download the file to UCCX.
- UCCX will ask us if we want to start the installation, go ahead and issue the command yes, and it’ll start. This is the part of the process that takes the longest. For me it took right at two hours to complete this process. This process is the actual upgrade process.
- Once the upgrade process is complete, it’s important to understand how UCCX manages this upgrade. This is the same for most Cisco collaboration products. The upgrade is installed to an inactive partition, meaning it’s there but it’s not in use. We will then have to issue a switch version, which will change the inactive to active and vice versa, and then reboot the system to the new version. That being said, we need to issue two commands, one is show version active, so that we again see our active version, then show version inactive. This inactive version is the version we are upgrading to.
- The next step will reboot the server, so make sure you’re ready for this. In order to make the new version live, we need to issue the command utils system switch-version. It will give us a warning and then ask us if we are sure we want to switch versions, so we will issue the command yes.
- DISASTER STRIKES! Ok, maybe it’s not THAT serious, but we did hit a problem. The switch-version failed. But why? Keep reading to find out…
- I went out to the web and searched the error, and rather quickly came across a Cisco documented bug that affects this version: CSCut04158
- Ok, so the bug says we don’t match the OVA template for this version, and that we need to modify the vNIC, the Guest OS version, as well as the vRAM to match requirements per the virtualization guide. So I went ahead and moved on over to the virtualization guide. You obviously want to review all of this before your upgrade to make sure your ESXi version is compatible, but it’s important to ensure you have the right hardware associated as well.
As you can see, the vRAM requirements are 10GB. So now let’s head over to our VMWare and see what we have there. But wait, doesn’t it say right that we only need the new OVA for fresh installs? Oh well, I guess that’s why it’s documented in a bug.
- Checking our vNIC, we are already set to VMXNET 3….
Checking our OS version we are already at Red Hat Enterprise Linux 6 (64-bit. The bug said Red Hat Enterprise Linux 5, but that SHOULDN’T be our problem.
A HA! We don’t have enough vRAM allocated. We only have 8GB and the requirements call for 10GB!
- So let’s fix this. First we need to shut down our UCCX server (GRACEFULLY! Meaning we do it through the CLI, not through VMWare).
- Now lets go upgrade our vRAM in VMWare.
- That looks better…
- Let’s power the server back on now.
- BE CAREFUL! Don’t try to do the switch version until your server is back up and all services have started. This may be 15-20 minutes…. You can issue the command utils service list to see where your services are at. Once they are all STARTED you can move on.
- After everything is back up and running, lets quickly confirm our inactive partition still has our new version.
- And lets move back to the switch version! Issue utils system switch-version and confirm with a yes when prompted. You will see our switch version begin. This process may take around 30 minutes or so to complete.
- This is a good sign!
- Once our reboot is completed, let’s log back in and do another version check to ensure our new version is now active and our old version is inactive.
- Once again we need to wait for our services to start up before moving on….
- Alright, so we need to confirm that our CTI ports are registered in CUCM. I’m going to check one that we built in a previous discussion about building a test app, which we are going to use now. Go ahead and check that out if you didn’t already. (hopefully you built it before you started this, if not, you can do that now that the upgrade process is complete) It looks like our CTI Port is registered, so we are good there.
- Now we can head over to Finesse and test using our test app that we built.
- It looks like calls are coming through, reports are loading, and everything is working as it should be. We have a successful upgrade!