Upgrades 101

30 May

I find the upgrade research process far more entertaining if you approach it like a less than ideal scavenger hunt – a poorly planned, slightly brutal game of talent and luck- mixed with just a pinch of despair.

In this example, which will not begin to cover all the ways/paths/routes you can go for an upgrade, we will take a common scenario and walk through the basic research process. This is more to outline the process and things you should be checking rather than trying to be a comprehensive list of links for upgrades.

I apologize in advance for all the links in this post that will inevitably become dead after a matter of time, but there’s only so much in the universe I can control. Also, I shouldn’t have to say this, but ALWAYS check the latest versions of the documentation – things change – but it’s highly unlikely I’ll modify this post to reflect it.  I’m just lazy that way.

Let’s say in our example you have 5 unified communications servers in your cluster and are looking to upgrade to the latest & greatest versions of each product:
2 Call Managers – MCS7825-H3 with 2×160 GB drives and 2 GB of memory running
1 Unity server – MCS7825-H3 with 2×160 GB drives and 2 GB memory running Unity 8.0
2 UCCX servers – MCS7825-H3 with 2×160 GB drives and 2 GB memory running 7.0(1)SR05_Build504

Let’s start with determining the upgrade path for your Unity server:
In case you have been living under a rock, the reign of tyranny Unity has enjoyed over voice engineers has been given an official end date, so if you are looking to upgrade your voicemail server, Unity Connection is the way to go.  The breeze with which this product installs in comparison to it’s predecessor will make you want to kiss your mother-in-law and hug your neighbor’s yappy little dog.

Step one in the Unity Connection research process is to determine your hardware compatibility. In this case, you get to play the find-your-server-model on the Big Long List ‘o Compatibility for the version you want to go to – in this case I pulled up the compatibility list for 8.x of Unity Connection:

In our current example, you can see that this model of server is supported for versions of Unity Connection 8.x.   Yay, you! Specifically, it’s supported for Platform Overlay 1 which requires 4 gig of RAM and 2 250 gig drives.

We will want to confirm that our proposed Unity Connection version is compatible with both our current version of CUCM and our proposed upgrade version of CUCM – this typically isn’t an issue since Unity Connection plays very nicely with almost all versions of CUCM, but definitely a check you want to make:

In the case of Unity Connection upgrades, you are going to want to look closely at the DiRT tool and the COBRAs tool to make the transition from the old to the new – there are excellent tutorials/instructions/information on this web page:

Moving on, let’s tackle the process of determining the upgrade path for CUCM:

Step one is once again to determine your hardware compatibility.  Find your model of server on this chart clearly constructed by evil forces seeking to wreak havoc on the universe:

Note that if you actually want to see your server model AND the headers at the same time, you are just out of luck unless you have a really, really large monitor or can read really, really tiny font. I’ve been known to take a screen shot of the header row and a screen shot of my server model row and line the two up. The entire time chanting curses upon the chart creators.*

As you can see, our example server does support CUCM 8.6 but there is both an X and a (2).  If you look at the sub notations on this already freaking fabulous chart (note sarcasm font), you will see indicators that while this server is supported, there are certain memory and hard drive upgrade considerations.

In this case, our sample server meets the hard drive specs (160 GB drives), but is going to need an extra two gig of RAM to make the leap into hyperspace. One note here, be sure to watch out for servers that are supported only for bridged upgrades – this means you can take the server up to the latest version, but the only thing it’ll be good for is to take a backup that can be restored onto a supported server. That, and I’m sure it makes a really useful, if somewhat noisy, door stop.

Once you’ve confirmed hardware compatibility of your CUCM servers, you will need to check your upgrade path.  Even though ideally you would like to go directly to the latest and greatest CUCM version, unfortunately you may run across a you-can’t-get-there-from-here scenario – especially if you are looking at upgrading from versions of 6.x.  In our sample case we are looking to go from to 8.6.2.  Time to pull out the magic eight ball.  Nah, actually, just use this document:

Note that you will likely need to know what your full version number translates to in SU-speak, in this case is actually 7.1(3a).  What you are looking for is your release in SU-speak under the Direct Upgrade column of the release you want to go to. If it’s not there, you are going to get to do a step upgrade – intermediate upgrades FTW! (sarcasm font again)

Be sure if you find yourself in this situation to pick a stable intermediate version.

The last piece of our CUCM cluster upgrade is UCCX (formerly IPCC):
Step one is, of course, to check the hardware compatibility, and there’s a doc for that:

This document may make your head spin a little, but first look for the version of UCCX you want to go with, in our case 8.5(1). Then check and see of your server makes the cut.

In our example case, we do make the cut – our version of UCCX 7.0(1)SR05_Build504 is even listed under supported upgrade paths- BUT looking at the document closely, UCCX 8.5(1) isn’t supported with our current CUCM 7.1.  Welcome back step upgrade.  You will need to keep your UCCX and CUCM versions compatible, so upgrading to UCCX to 8.02 then upgrading CUCM to 8.6, then upgrading UCCX to 8.5(1) will do the trick. And lead to excessive drinking.

Note, however, that our example CUCM version is not explicitly listed in the chart- only 7.1(3) and 7.1(3b) – so if it were me, I would confirm with Cisco support that 7.1(3a) indeed did support UCCX 8.02. Make no assumptions when it comes to the documentation- ever.

After you’ve survived all of this, I’d say your about 1/2 way through the research process.  Among other things, you will still need to review the release notes for each application, check for COP file requirements, check the prerequisites for each proposed version, and confirm phone firmware compatibility. You will also need to check third party application support for all your extra voice applications**, determine the order in which the upgrades need to happen, and review detail over again***.  You’ll also need to determine down times and back out options should upgrades not go as planned. Of course upgrades always go as planned, right? (sarcasm font at it’s finest)

This will get you started on your hardware check, help determine if you need to invest in new servers, and give you an idea of what version you should be targeting and what it’s going to take to get your hardware there.

*To say I hate this chart with the passion of a thousand suns is a woefully pathetic understatement. If it burned in the fires of Hades for all eternity, that wouldn’t be long enough.
**Be sure not to forget to check the compatibility for your Presence servers, your CER servers, your recording servers, your paging servers, your fax servers, your voice gateways, your legacy PBX, and anything else that integrates with CUCM
***Note that in some cases you may actually lose some functionality your users are dependent on, specifically I would mention the loss of built in Attendant Console when making the jump to CUCM 8 and above. Double check everything for gotchas and caveats, it’ll save your arse and your upgrade.


Tags: , , , , ,

11 responses to “Upgrades 101

  1. Jschrein

    2012/05/30 at 16:57

    Reading this article I’m more and more thinking that buying a couple UCS servers and virtualizing it all is the way to go. Can you think of any reason not to?

    • amyengineer

      2012/05/30 at 17:15

      Not really – cost maybe- if you only have one server the numbers may not justify it, but MCS servers are on the way out. Also fixed MOH devices using USB connection, that could pose a problem when talking virtualization

      • william bell

        2012/06/10 at 09:10

        Amy, great write up and good note on the MOH integration. The fixed MOH is one of those things that is easy to overlook and can bite you. I basically see two options. Option 1, deploy a CUCM node that is running on MCS. Not very appealing if you are trying to move to a pure VM solution.

        Option 2, leverage a system outside of the cluster to provide the streaming. This external device must be able to accept a feed from the audio receiver and stream it via IP. The only way to make it usable is if you are using IP multicast. So, your network (at least the portion you want to carry MOH) must support multicast.

        With option 2 you still configure the CUCM MOH/MRG/MRGL as normal for mcast support. So, from the CUCM perspective it is streaming audio to a mcast group. At the first hop router for the CUCM MOH node, you block mcast traffic (disable PIM or use ACL). On the “new” external streaming device, configure the same mcast groups used by CUCM and allow that traffic to span the network.

        It’s a shell game!

        The external streaming device I have used is from Barix. It worked like a champ, supported PoE, and was highly configurable.


    • amyengineer

      2012/05/31 at 07:48

      Thought of another reason, old PIMG units that only support serial integration, those won’t work with virtualization. Would have to be replaced.

  2. Pat Jensen

    2012/05/30 at 19:40

    This is a great article Amy! Thanks for posting.

    I thought I’d add a couple of additional tips here that I think make a difference on a smooth upgrade process.

    As you are going through the planning process that Amy mentioned above, spend some time with the PUT tool, both in understanding and tracking your UCSS contract entitlements. When you order a media kit for an upgrade, you should expect a week or two for order fulfillment as well as getting an updated license generated.

    One advantage to ordering medias kit from PUT (instead of downloading from CCO) is that they can be used for both a bootable new installation and an upgrade. This is important when doing disaster recovery, step upgrades, or migrating to a new UCS server for instance.

    If you download an upgrade ISO on CCO, it can only be used for non-bootable upgrades and not migrating to new hardware or fresh installations. Smartnet covers minor upgrades, and UCSS covers major upgrades.

    When you migrate from one hardware platform (say non-virtualized MCS) to another hardware platform (UCS) this process is called rehosting. As you are going through the upgrade process, send an e-mail to and explicitly say you are rehosting your server. Include as much information as possible – such as any PO/SO order #s for your existing licensing or new server, UCSS contract numbers, as well as MAC addresses for both old and new servers.

    Pro-Tip: include a line item number on your SO for your UCL/CUWL licenses part number for much faster processing.

    If you are moving to a virtual environment, make sure to supply the License MAC in the application, not the hardware MAC or virtual MAC address. You can find this by doing a “show status”. If you can include the above information, you can get your licenses cut within an hour or two – with that being said, include these efforts in your project plan and do it as early as possible.

    • amyengineer

      2012/05/30 at 20:14

      Thanks for the additions, great advice!!

  3. James Buchanan

    2012/05/31 at 07:32

    Excellent article. One suggest re: MOH. Syn-Apps makes a nice adapter that will take the live feed and multicast it. This can also be done via E&M or FXO, but the Syn-Apps paging relay really does a nice job for about the same cost.

    • amyengineer

      2012/05/31 at 07:44

      Thanks for the tip! I’ll have I check that one out!

  4. TimmyZ

    2012/05/31 at 20:57

    I love this article because I just lived it. I was blown away with the intermediate step and really brought the upgrade to a halt. Then I really ticked a user off when Attendant Console was removed. All in all I did the upgrade just for UCCX (which I really appreciated your previous post on UCCX and recording. I checked codec before it checked me).

  5. Jason Faraone

    2012/06/07 at 10:50

    I virtualized my entire environment and haven’t regretted a single thing. 3 X CUCM, 2X Unity Connection, 1X CCX. The upgrade planning was a nightmare, though; I was transitioning from Exchange 2003 to 2010 at the same time.

  6. jplaskett

    2012/09/01 at 14:01

    Another great topic! I’m thrilled to find a blog about my career and that so many other Engineers are experiencing the same trials and tribulations that I do! Sometimes I get lost in my Voice war feeling like I am a lone soldier on a front all alone! Lol!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: