CallManager/Unity shenangigans

A quick background on this.

CallManager 5.1.3

Unity Express 1.2

Both on old MCS servers. Callmanager is redundant publisher/sub-pub. Unity, unfortunately is not (an oversight done before my time), however we do have a spare MCS server from a previous appliance now unused that I was able to utilise (see below).

The new servers were lovely UCS C200 appliances, so we were going virtual.

The upgrade path to 8.6 and above is a very interesting and convuluted process.

I may be overdoing it, but this is the process I had to take in my lab, before looking at our production infrastructure.

UCS

  • Prepare the new appliances as per the instructions.

CallManager

  • Upgrade our existing servers from version 5.1.3 to 7.1.3. This can be done on the fly, as there is an active and passive partition on each server. You reboot one, then once it’s up, reboot the next..calls don’t drop.
  • Switch over to the new version
  • Apply new licenses. Version 7.1.3 has new services that 5.1.3 did not require licenses for, so this must be done
  • Take a backup of the new 7.1.3 servers.
  • Deploy the UCS virtual machines
  • Install version 7.1.3 on the new VMs (This could be done earlier if need be probably more time efficient). Make the IP different to the current CallManager for now, to avoid address conflicts. If you are planning on different IP’s anyway, fine, but remember to change any voice gateways you may be using as well. I just planned for a maintenance window, so I left things as is.
  • Do a restore of the backup just taken.
  • Shut down the old CallManager and change the IP of the new CM to its old one. At this stage, the UCS CM will now become the live.

  • Run the ciscocm.refresh_upgrade_v1.0.cop.sgn patch, which is needed before the jump in OS. Run this on each machine in the cluster.
  • Upgrade to version 8.6. This is a refresh upgrade, so multiple reboots will be required.

Unity Express

  • Format the fresh physical server we had sitting there doing nothing.
  • Take an export of the Unity database with the COBRAS tool.
  • Install version 7.1.3 freshly onto the physical server and restore the backup just taken.
  • Apply new licenses
  • Prepare the UCS VM’s
  • Install version 7.1.3 on the VMs
  • Restore the backup just taken so the VM Licenses that were on the backup will be applied
  • Deploy the next Unity VM straight to 7.1.3 with a new IP and the database will replicate over once configured in the cluster options. You will now be able to fail machines over without interruption.
  • Run the ciscocm.refresh_upgrade_v1.0.cop.sgn patch, which is needed before the jump in OS, due to the switch from RHEL 4 to 5 as a base OS.
  • Upgrade to 8.6. This is a refresh upgrade, so multiple reboots will be required.
  • Deploy the next Unity VM. Set up the clustering in the primary Unity server and make sure the database replicates over.

Notes:

  • The ciscocm.refresh_upgrade_v1.0.cop.sgn patch. This is a gotcha that Cisco don’t make you terribly aware of in the upgrade notes, however they do mention it elsewhere.

Thanks to http://networkingnerd.net/2011/12/12/moving-to-cucm-8-6-youll-never-upgrade-me-alive-coppers/ for shedding light on this.

  • When switching versions initially, or after upgrading, you may find the version does not switch (This happened to me from 7.1.3 to 8.6). You may need to log into the box in question and do a
Admin: utils system switch-version

This will force the box to switch partitions. It may take a good minute for the box to switch and then reboot, so keep an eye on the console. You may also see the machine install new Vmware tools and restart again because of it.

  • After a reboot,  the machines may take some time (a minute say) to again display the web portals. Tomcat just takes its time restarting that’s all.
  • Technically, CM/Unity 7.1 is NOT supported on Vmware. So each time you power down the machines and power them back up, you may get a warning, plus have to agree to the terms and conditions before the machine keeps booting. Once you upgrade to 8.6, this won’t happen. I have had some people on 7.1.2 with this issue. I didn’t have the issue on 7.1.3- however the upgrade matrix requires 7.1.3 as the minimum 7 platform for any upgrade to 8.6.
  • When initially deploying the VMs for both Unity and CallManager, you MUST make sure the NIC is NOT a Flexible NIC. It MUST be an E1000 type. I saw  duplex mismatches between the devices and the core switches in the lab.

They were automatically set as 100/Full, but the switch was reporting them as negotiating them at 100/half-duplex. Removing the Flexible NICS and readding as E1000′s did the trick. Or you could just deploy as E1000 out of the box by modifying the machine after the machine is deployed and before it is powered on.

See what I mean by being convoluted?

Tagged , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *