CUCM Upgrades and Migrations FAQ

From DocWiki

(Difference between revisions)
Jump to: navigation, search
(What is the Drive To Collaboration program??)
(Upgrade to 12.0 OS change)
Line 19: Line 19:
There has been an OS change, '''not just version''', in CSR 12.0 we're no longer using RHEL variants, now we have switched to CentOS and that's the guest OS you need to choose: CentOS 4/5/6 (64-bit)
There has been an OS change, '''not just version''', in CSR 12.0 we're no longer using RHEL variants, now we have switched to CentOS and that's the guest OS you need to choose: CentOS 4/5/6 (64-bit)
 +
 +
'''UPDATED 9/11/2018'''<br>
 +
The reference to this change is called out in the OVA README<br>
 +
[https://www.cisco.com/web/software/283088407/139512/cucm.ova.README_12.0.pdf Cisco Unified Communications Manager (CallManager) 12.0 Virtual Server Template (OVA)]
Go to [[CUCM Upgrades and Migrations FAQ#top|CUCM Upgrades and Migrations FAQ Content Table]]
Go to [[CUCM Upgrades and Migrations FAQ#top|CUCM Upgrades and Migrations FAQ Content Table]]

Revision as of 16:40, 11 September 2018

CUCM Upgrades and Migrations FAQ placeholder

Back to Unified Communications FAQ
Back to CUCM FAQ

Contents

How can I get bootable media??

If you're searching for bootable media for CUCM, IM&P, CUC, etc. I'm sorry to disappoint you, but you won't find them there. We don't post bootable images, for the few products you can download the images, most likely it's actually an OVA, and either it won't require licenses, or you'll need licenses for it to work.
If you need bootable media for a fresh install, upgrade, or adding a SUB, you'll need to order it via PUT
There is a method out there for making upgrade ISOs into bootable media, I won't go into details, I just need to make it very clear, that doing so, will result in an UNSUPPORTED SYSTEM, if you want to use it for lab purposes, go right ahead, but don't use this for production environments, if you're in a hurry for bootable media, reach out to TAC, or your SE so they can assist.

Go to CUCM Upgrades and Migrations FAQ Content Table

Upgrade to 12.0 OS change

VERY IMPORTANT
The CUCM 12.0 upgrade guide doesn't explain this in detail, it only shows:
Change Virtual Machine Configuration Specifications

Change the Guest OS version to match the requirements of the new release.

There has been an OS change, not just version, in CSR 12.0 we're no longer using RHEL variants, now we have switched to CentOS and that's the guest OS you need to choose: CentOS 4/5/6 (64-bit)

UPDATED 9/11/2018
The reference to this change is called out in the OVA README
Cisco Unified Communications Manager (CallManager) 12.0 Virtual Server Template (OVA)

Go to CUCM Upgrades and Migrations FAQ Content Table

How do I know if I can upgrade from X version, to Y version of CUCM??

UPDATED 6/7/2018
The latest upgrade guides (10.5, 11.5 and 12.0) have been revamped and now they include within them the valid upgrade paths from each release. It's mandatory to review the specific upgrade guide for the target version, as well as the Release Notes. All the information related to valid upgrade paths can be found within them, including special scenarios when upgrading from certain SUs, in which you cannot upgrade to a major release base version due to new features/enhancements that might have been implemented and to which specific SU you need to upgrade.
That seems to be counter intuitive, doesn't it? but it's based on the release date.
For example (and I'm making this example up) if you are running 9.1(2)SU8 and you want to upgrade to 10.5(2), you will not be able to. Why? because SU8 is newer than base 10.5(2) and there are changes that you will lose if you do that upgrade. Let's say that the same changes were implemented in 10.5(2)SU4e, then you would need to upgrade to that release, or higher.

This is a real life example as I just upgraded my lab to 10.5(2)SU7, from the Readme:

Warning for Upgrades to 11.0(1)

  • This SU adds support for future Cisco products. These products are not found in CUCM 11.0(1) as that version was released prior to development of these products. Upgrades from this SU to any 11.0(1) version will display a database migration failure as these new products are not included in 11.0(1) Customers migrating from this SU should choose 11.5(1)SU2 or higher as their target upgrade.

Warning for Upgrades to 11.5(1)

  • This SU adds support for future Cisco products. These products are not found in versions of CUCM 11.5(1) prior to 11.5(1)SU2 as those versions were released prior to development of these products. Upgrades from this SU to any 11.5(1) version prior to 11.5(1)SU2 will display a database migration failure as these new products are not included in releases of 11.5(1) prior to 11.5(1)SU2. Customers migrating from this SU should choose 11.5(1)SU2 or higher as their target upgrade.

The Readme is usually found when you go to the downloads area of cisco.com, you find the upgrade image you will use, and hover over it. In this example, this particular file had 2 Readme file, one for CUCM and another one for CUC.

End of update

Starting with version 10.x a separate document was developed with compatibility information, it can be found here:
Compatibility Information

So, you have the links, how do you tell if you can upgrade or not??
I'll give you an example, lets start by noticing that the install and upgrade images have a common name, and a "technical name".

  • 9.1.2.13900-10 is the technical name of 9.1(2)SU3
  • 9.1.2-10000-28 is the technical name of 9.1(2) (and we'll use this one for the starting point in the example)

Why is that?? I dare you to remember the versions with all the numbers, it's just easier to remember them with a common name.

So, first step, identify your CUCM release. If you're running a version that does not show in the tables, most likely it's an ES version.
ESs are based on a MR (Maintenance Release) image, so, if you're running something like 9.1.2.11987-42 (I'm just making that up for the example) that would be based on 9.1.2.11900-12, which is 9.1(2)SU1, so consider that your starting point.

You know which version you currently have?? Great, now, next question:
To which version do you want to go??

Well, I'd like to go, I don't know..., 10.5(2)??
Fine choice, that's the current MR for the 10.x train (I already explained why you want to be in a MR in another question), OK, let's take a look at the Compatibility Information for Cisco Unified Communications Manager Release 10.x

If you click on: Upgrade Paths for Cisco Unified Communications Manager Release 10.5(2)
You'll see the release you want to get is: 10.5.2.10000-5
Now, lets review the Direct upgrade section:

Direct Upgrade:
10.5(1)SU1a, 10.5(1)SU1, 10.5(1), 10.0(1)SU2, 10.0(1)SU1, 10.0(1), 9.1(2)SU3, 9.1(2)SU2a, 9.1(2)SU2, 9.1(2)SU1, 9.1(2), 9.1(1a), 9.1(1), 9.0(1), 8.6(2a)SU5, 8.6(2a)SU4a, 8.6(2a)SU4, 8.6(2a)SU3, 8.6(2a)SU2, 8.6(2a)SU1, 8.6(2a), 8.6(2), 8.6(1a), 8.6(1)

OK, you can see your version listed there, but you may ask, Why does one section says Direct Upgrade and the other one Supported??

Ok, now knowing that you can do a direct upgrade to 10.5(2) from, pretty much, any 9.1(2) version we can proceed.

What's next???
The next step, would be to make sure your HW is supported for your target release How do I know if my HW is supported??

You want to make sure your HW supports the target version you want to go before proceeding with the rest of the documentation you'll need to read to proceed, if it's not supported, you would need to re-do the above steps with a version that is supported by your HW, then come back to this point of the procedure.

So, we assume your HW is supported for the upgrade, now, we need to read some more documents which will outline the upgrade procedure, and any special requirements we might need.
You will need to read the:

  • Upgrade guide for your target CUCM version
    Install and Upgrade Guides
  • The Release Notes for your target CUCM version
    Release Notes
  • If applicable, as it depends on the CUCM version, the separate New and Changed Information for CUCM x.x document
    In newer releases, this has been added as a chapter in the Release Notes. If there is a separate document, it can be found along with the Release Notes

Why is that?? Between the 2 (or 3) above docs, you will gather all you need to know for the upgrade to succeed, any pre-reqs that you might need, the actual procedure for the upgrade, and any post-upgrade procedures/changes will be outlined in them.

There is no cutting corners on this, you need to do your due diligence, and read the docs to get all you need, there are way too many options to provide guidance on every single upgrade path. The above is to provide you with the basic workflow you would need to do for any upgrade

A scenario I did not cover was upgrading from versions not listed in the upgrade matrix
What If I'm running CUCM 5.1(3) and I want to upgrade to 10.5(2)??
Well... you're in for a ride as you'll need to perform this in multiple hops to get to a version that allows you to upgrade, remember there is a difference between a Direct Upgrade and a Supported upgrade, so, if you want to be able to perform a PCD migration, you would need to go to 6.1(5) at the very least, if you want to be able to perform a direct upgrade, the last release to which you could upgrade directly from 5.1(3) would be 7.0(2a), which is not able to upgrade to 8.6(1), the earliest release for that would be 7.1(3), so an example path would be 5.1(3) -> 7.0(2a) -> 7.1(3) -> 8.6(1a) -> 10.5(2). A simpler path might be 5.1(3) -> 6.1(5) -> 8.6(1a) -> 10.5(2).
At this point you might ask: How come 6.1(5) can upgrade to 8.6(1a) but 7.0(2a) cannot??
To which the answer is: Because 6.1(5) was considered a MR, whereas the 7.0(x) train was not.

Go to CUCM Upgrades and Migrations FAQ Content Table

Why does one section says Direct Upgrade and the other one Supported??

UPDATED 6/7/2018
Most newer releases (8.6+) are all capable of doing a direct upgrade to the most up to date releases (12.0 as I write this) and a lot of the information from this questions is no longer applicable unless you're running releases below 8.x


Directed Upgrade Vs. Supported upgrade in the 10.x compatibility guide, why's that?? What's the difference??

Well, when PCD came into the play field, things changed a bit.

Let's take a look at the upgrade path for CUCM 10.5(2) for Direct Upgrade:

  • Direct Upgrade:
    10.5(1)SU1a, 10.5(1)SU1, 10.5(1), 10.0(1)SU2, 10.0(1)SU1, 10.0(1), 9.1(2)SU3, 9.1(2)SU2a, 9.1(2)SU2, 9.1(2)SU1, 9.1(2), 9.1(1a), 9.1(1), 9.0(1), 8.6(2a)SU5, 8.6(2a)SU4a, 8.6(2a)SU4, 8.6(2a)SU3, 8.6(2a)SU2, 8.6(2a)SU1, 8.6(2a), 8.6(2), 8.6(1a), 8.6(1)

Upgrade Paths for Cisco Unified Communications Manager Release 10.5(2)

Now, let's take a look at the PCD information for upgrades:
Upgrade Task - (Upgrade Application Server or Install COP Files)

  • Unified CM Releases Supported: 8.6(1-2), 9.0.(1), 9.1(1), 9.1(2), 10.x

Supported Releases

Notice any similarities in the versions that are supported??

Direct Upgrade means that PCD can invoke the upgrade process in the UCM server and upgrade on the same server. This has only ever been supported on UCM 8.6 and later. There is no support for Direct Upgrade to 10.x from anything PRIOR to 8.6.

Now, there is also a Supported upgrade section for the same CUCM release that shows:

  • Supported: (Consult the Cisco Unified Communications Manager Upgrade Guide for details)
    8.5.(1)SU7, 8.5.(1)SU6, 8.5(1)SU5, 8.5(1)SU4, 8.5(1)SU3, 8.5(1)SU2,
    8.5(1)SU1, 8.5(1), 8.0(3a)SU3, 8.0(3a)SU2, 8.0(3a)SU1, 8.0(3a),
    8.0(3), 8.0(2c)SU1, 8.0(2c), 8.0(2b), 8.0(2a), 8.0(2), 8.0(1),
    7.1(5b)SU6(restricted), 7.1(5b)SU5(restricted), 7.1(5b)SU4(restricted),
    7.1(5b)SU3(restricted), 7.1(5b)SU2(restricted), 7.1(5b)(restricted),
    7.1(5a)(restricted), 7.1(5)SU1a(restricted), 7.1(5)SU1(restricted),
    7.1(5)(restricted), 7.1(3b)SU2, 7.1(3b)SU1, 7.1(3b), 7.1(3a)SU1a,
    7.1(3a)SU1, 7.1(3a), 7.1(3), 6.1(5)SU3, 6.1(5)SU2, 6.1(5)SU1,
    6.1(5), 6.1(4a)SU2, 6.1(4a), 6.1(4)SU1, 6.1(4)

Can you upgrade from some of those CUCM releases to CUCM 10.5(2) "directly"??
And I mean by "directly" that you just might need to install a few COP files for that to work, yes, you can. That's what makes the difference between one release being listed under Direct Upgrade, or being listed under Supported, read this snip from the 10.5(2) RNs:

Preupgrade COP File

If you are upgrading to Cisco Unified Communications Manager Release 10.5(1), or later, from a release earlier than Cisco Unified Communications Manager Release 10.0(1), you must download and install ciscocm.version3-keys.cop.sgn on every node in the cluster. This Cisco Options Package (COP) file has the RSA keys that are required to validate the upgrade. Missing RSA-3 keys will result in status errors in the Software Installation/Upgrade window of the Cisco Unified Operating System Administration interface.

If you are upgrading to Cisco Unified Communications Manager Release 8.6 or later from a release earlier than Cisco Unified Communications Manager Release 8.5, you must download and install the latest ciscocm.refresh_upgrade_version.cop.sgn on every node in the cluster.

IMHO, if you can upgrade by just installing the required COP files, it should be listed as Direct Upgrade, as it was in the past.

Now, you'll see some pretty old CUCM releases are there under Supported (6.1(x) - 7.1(x)), does that mean you can actually upgrade to 10.5(2) from them??
Well... no, and that is another thing that changed with PCD (and the jump upgrade procedure), and is not explained as it should be here. You can migrate from them, and that is a whole different story.

Let's go back to documentation on PCD and Jump upgrade:

PCD shows:
Migration to 10.x Cluster

  • Unified CM Releases Supported: 6.1(5), 7.1(3), 7.1(5), 8.0(1-3), 8.5(1), 8.6(1-2), 9.0.(1), 9.1(1), 9.1(2), 10.0(1)

Jump upgrade shows:
If you are upgrading to Cisco Unified Communications Manager Release 9.1(2) from an older release and a direct upgrade from that release is not supported, you can follow the jump upgrade procedure. The jump upgrade procedure allows you to upgrade to an intermediate release on UCS hardware and then migrate to a virtualized platform. This document provides procedures for performing a jump upgrade to Release 9.1(2) using the following intermediate releases:

  • 6.1(4)
  • 6.1(5)
  • 7.1(3)
  • 7.1(5)

So, for many old releases you can "upgrade" via a migration from PCD

Migration is when PCD extracts the data from a UCM server, then builds a new cluster and imports that data. (More info on PCD procedures, what's the difference between an upgrade and a migration??, etc. can be found HERE

To summarize: Direct Upgrade supports 8.6 and later while Supported (aka Migration) supports 6.1(4) up to 8.5(1)

This bug has been created in order to remove some of the confusion around this:

  • CSCus62385 DOC: Direct upgrade is not supported from 7.1.5 to 10.x

Go to CUCM Upgrades and Migrations FAQ Content Table

Can I upgrade directly from an 8.x release to 10.x or 11.x??

This is actually an interesting question, for a long time, the assumption was that you required to upgrade to 8.6 to perform a direct upgrade to 10.x or 11.x, however, I recently did a test in my lab running 8.5(1)su7, and was able to upgrade to 11.x by just installing the RU and V3 RSA keys COP files. I did the test because I found it weird you had to do a minor upgrade to 8.6 (which adds time to the overall procedure) before you could upgrade to 10.x+

Now, as I explain in the above two questions, the compatibility matrix for CUCM is now geared a bit more towards what you can do with PCD Vs. what you can do with just CUCM and a manual upgrade. PCD will not let you upgrade an 8.5(x) release, nor install a COP file to it. But that doesn't mean you cannot do it the old fashioned way.

We recently found this bug, which is just over two months old from the date I'm writing this:

  • CSCus62385 DOC: Direct upgrade is not supported from 7.1.5 to 10.x

As you can read, it actually states that a direct upgrade, is possible, and supported from an 8.x release to 10.x (and as I tested, also for 11.x). It's only when you're running a pre 8.x release that you need to upgrade to 8.6 to then upgrade to 10.x+ (or at least that's the recommendation, I'd probably also recommend the same if it was up to me).

Go to CUCM Upgrades and Migrations FAQ Content Table

How do I know if my HW is supported??

If you're already running CUCM 8.0(2a)+ over ESXi, you then need to read this What possible HW options do I have to install CUCM?? to confirm your HW is supported for the upgrade to the version you want to go, the theory remains the same as if you were going to do a fresh install.

I did not cover MCSs under installs, as no one should be deploying any MCSs right now, you should already be working over ESXi, or looking into it for new installs.
I will cover MCSs only for upgrades, as this would be a scenario that still be faced by a lot of people, making sure your MCS server is supported for a particular version is far easier than doing the same with UCSs / 3rd party specs-based, all you need to do, is look at this link and match your server model Vs. CUCM version.

Supported Servers for Releases of Cisco Unified Communications Manager (Including Business Edition 3000/5000/6000 and Session Manager Edition) and Cisco Intercompany Media Engine

Make sure to read the footnotes if they apply to your MCS and CUCM version in the table, notice that for some reason they decided to say strongly recommended instead of required. If you're going to simply use the server as a jump server ("bridged upgrade" is what they call it in the link), bear in mind that we will not support you using it for a production network.

If you're running a 3rd party server (IBM or HP), then you need to visit this page:
Cisco 7800 Series Media Convergence Servers
To match the specs from your server against those of an MCS, and determine to which MCS model your server is equivalent, to then review the above documentation.

Go to CUCM Upgrades and Migrations FAQ Content Table

How can I check the ESXi compatibility with my applications??

There is a tool which you can use to verify supported ESXi releases on your server:
UCS HW and SW Interoperability

As for the apps, each one introduces ESXi support depending on the testing from the BU and they might be supported at different dates, this is important to consider, specially with ESXi 6.x now available. For example, if you have 6 apps, and 4 have been qualified for ESXi 6.x, but other 2 still show 5.5 as latest, you would have to choose between using a separate server for the apps, to wait until all apps are supported on 6.x, or to upgrade to 6.x and lose support until they have cleared all the test and we approve compatibility.

You would need to go to the Cisco Collaboration Virtualization and click on the products you're interested in, they will list ESXi compatibility under each release.

Go to CUCM Upgrades and Migrations FAQ Content Table

How can I check compatibility with other applications??

There are several links in which compatibility with other products is covered, you should also review the other product documentation to confirm compatibility:

Go to CUCM Upgrades and Migrations FAQ Content Table

How can I tell if my OVA is supported for a newer release??

The only method is to look at your OVA specs and compare them against those of the VM settings for your target release here: Cisco Collaboration Virtualization
If you need to perform any adjustments, shut down your VM and perform the changes so that the upgrade procedure won't stop because of not-supported VM specs.

Go to CUCM Upgrades and Migrations FAQ Content Table

To which CUCM release should I upgrade??

The official answer, is that we recommend you to be in the latest CUCM release available.

If there is any new X.0 or X.5 release, you can pick either. The quality gap that used to exist between the X.0 and X.5 is no longer present as the engineering team spends the same amount of time and engineering resources in either release. If you decide to wait before picking up a X.0 or a X.5, then pick up the first SU after both a X.0 and a X.5. It is where a lot of the initial issues found from new features in the field gets fixed.

As a general rule, CUCM end of sale a .0 release when the N+1 release is delivered. e.g. 11.0 went end of sale when 12.0 came out. For .5 releases we end of sale when the N+2 release comes out. e.g. 10.5 will end of sale when 12.5 is released.

Go to CUCM Upgrades and Migrations FAQ Content Table

What is a CUCM MR (maintenance release)??

A MR is a version on which the BU is still investing effort in developing, and fixing issues, some releases have very short life-spans and are replaced by the MR, for example:

  • The moment the 9.1(x) train was released, 9.0(x) was deferred, and 9.1(x) became the MR for the 9.x train
  • Very similar situation to 10.0(1) and 10.5(1), right now the MR for the 10.x train is 10.5(2)
  • for 8.x train, 8.6(2) is the MR
  • For 7.x train, 7.1(5) is the MR
  • For 6.x train, 6.1(5) is the MR

So, why do you want to be in a MR??
Because these are the versions that will receive fixes for most bugs, and any major problems. For example, when the openSSL heartbleed vulnerability was discovered, if I recall correctly, the fix was released for 8.6(2), 9.1(2) and 10.0(x) releases (That was the most recent 10.x release as far as I recall). No fix for 8.5(x) or 9.0(x).

Another reason, DevPacks are usually no longer developed for anything but MRs, so, if you're running 9.0(1) and want to use any of the new endpoints that are enabled via a DevPack, you will need to upgrade to 9.1(2), and then apply the DevPack.

Yet another reason, usually this releases become the most stable releases of the whole train, I personally love 8.6(2), and these are the ones that have the longest support span.

Go to CUCM Upgrades and Migrations FAQ Content Table

What are the steps for an upgrade??

The main steps for any upgrade vary very little between versions. The most important part of this, is actually making sure everything is in place before you load the ISO and try to perform the upgrade.

The Install and Upgrade guides outline many of the things covered in this FAQ and the actual process, the Release Notes elaborate on any specifics that you might need to have in mind.

As I mentioned, the process will be almost the same for all upgrades, one of the few things that will be different, depending on the upgrade path, is whether you need to change to the new version as the installation finishes, or if you first install it in all your servers in the cluster, to then proceed with the switching. Put close attention to that detail.

UPDATED 6/7/2018
The 10.5, 11.5 and 12.0 upgrade guides have been revamped since me writing this, they now have all the information that is required for an upgrade. They are the mandatory reading for any upgrade, along with the Release Notes and README that comes with the ISO image available on cisco.com

Go to CUCM Upgrades and Migrations FAQ Content Table

What should I verify / do / check before the actual upgrade??

In first place, make sure to review the upgrade guides, Release Notes and README (available with the ISO image available to download on cisco.com)for the product.

  • Make sure you have around 25 GB of free space in your /common partition, you can find that from cli, run show diskusage common
  • Make sure to DRS backup your cluster
  • You may require COP files depending on your upgrade path. What COP files do I need??

Go to CUCM Upgrades and Migrations FAQ Content Table

What COP files do I need??

I'll cover the main 4 COP files that might be required for any upgrade. Bear in mind this is CUCM specific, there might be other COP files required for other products, and only for specific SUs. This is why it's extremely important to review the proper documentation before an upgrade.

ciscocm.version3-keys.cop.sgn
ciscocm.refresh_upgrade_v1.5.cop.sgn
ciscocm.vmware-disk-size-reallocation-1.0.cop.sgn
ciscocm.free_common_space_v1.3.k3.cop.sgn

The path where they can be found (as I write this) is the following:
Downloads Home > Products > Unified Communications > Call Control > Unified Communications Manager (CallManager) > Unified Communications Manager Version 8.6 > Unified Communications Manager / CallManager / Cisco Unity Connection Utilities-COP-Files

NOTE Versions might change in the future, you should always use the latest one available. If you search the files on cisco.com with the name just before version, you should find them quite easily.

So, when and why would you need them??

  • ciscocm.version3-keys.cop.sgn
    This file is required as we changed the RSA keys we use to sign all of our images (ISO, COP, etc.)
    If you're upgrading to CUCM 10.x from any previous version, you'll get an MD5 error if you don't have it installed.
    New FW images, and DevPacks (as an example) are also being signed with the new keys, so, if you're running anything prior to 10.X, you might still get an MD5 error, you'll also need to install this COP to be able to install them. README
  • ciscocm.refresh_upgrade_v1.5.cop.sgn
    The README says:
    To upgrade from Release 8.5(x) or earlier to Release 8.6(x) or later, you must apply this patch before initiating the upgrade. Some 8.5(x) or earlier ES/SU versions already contain all the changes that are delivered by this patch and do not require this patch. The refresh upgrade COP file delivers changes to the user experience on the CLI and GUI that are related to a refresh upgrade, and basic functionality needed to support refresh upgrades. Refresh upgrade is a new feature in 8.6(x) that allows upgrades between incompatible OS versions.
    Basically, you need this if you're running 8.5(x) and below, and you plan to upgrade to 8.6(x) and later releases in order to allow the upgrade from RHEL 4 to RHEL 5, and future RHEL upgrades.
  • ciscocm.vmware-disk-size-reallocation-1.0.cop.sgn
    README. You basically want to install this when you want to increase the /common partition, in order to allow upgrades to succeed and to increase logging capacity. You ONLY need this COP if you're running CUCM 9.1 and below. CUCM 10.x+ code already has this ability built-in. Related: How can I add space to my VM HDDs if required??
  • ciscocm.free_common_space_v1.3.k3.cop.sgn
    From README:
    When upgrading from an older version of Unified Communications Manager to Release 9.1(x) or later, the system runs out of disk space in the common partition.
    As you know, each CUCM upgrades requires some free space in order to process the files, when you're running out of space, and don't mind the contents of the /common partitions to be removed.
    A few comments about this particular COP:
    • It will not work if you have more than 25 GB of free space in /common partition
    • This COP file is signed with RSA V3 keys. If your product does not support RSA V3 keys, you may have to install ciscocm.version3-keys.cop.sgn first before installing this patch.
    • You will NOT be able to perform a rollback to the version in the inactive partition if required.
    • If you don't like any of the above 3 points, then you probably want to increase the /common partition size to have enough space for the upgrade to succeed.

Go to CUCM Upgrades and Migrations FAQ Content Table

Do I need to modify the VM settings??

It depends on the upgrade path:

  • To CSR 12.x
    • RHEL is no longer used an the Guest OS has to be changed to CentOS 4/5/6 (64-bit)
    • VMXNET 3 remains the vNIC in use
  • From 9.x to 10.x / 11.x
    • You need to change the OS from RHEL 5 to RHEL 6
    • You need to change the vNIC to VMXNET 3
  • From 8.6 to 10.x
  • From 8.6 to 9.x
    • No changes required
  • From anything below 8.6, to 8.6
    • You need to change the OS from RHEL 4 to RHEL 5

UPDATED 6/7/2018
The 10.5, 11.5 and 12.0 upgrade guides have been revamped since me writing this, they now have all the information that is required for an upgrade. They are the mandatory reading for any upgrade, along with the Release Notes.

Go to CUCM Upgrades and Migrations FAQ Content Table

How to change the vNIC to VMXNET3??

UPDATED 6/7/2018
I show the procedure in this video: How to upgrade a CUCM/CUPS 8.6 to CUCM/IM&P 11.0

The whole procedure is outlined in the CUCM 10.0 OVA README

Modifying the Network Adapter:

  • First, confirm whether the existing network adapter is configured with a manual (static) or automatic (dynamic) MAC address
  1. Navigate to the Summary tab for the VM in question, choose "Edit Settings"
  2. Choose "Network adapter 1" and check whether the radio button in the MAC Address section is selected for "Automatic" or "Manual" (do NOT make any changes)
  3. select a) or b) below accordingly and follow the steps. If you have the proper VMware license you can also use the PowerCLI method c) below instead of a) or b). The PowerCLI method is applicable for both Automatic and Manual MAC address configurations


a) If the existing network adapter is configured with an **Automatic** (dynamic) MAC address, the administrator needs to modify the virtual machine configuration file. For tips on how to edit the vmx file, see "Tips for editing a .vmx file" (http://kb.vmware.com/kb/1714).

  • Before you edit the .vmx file be sure to do the following:
    • The file has a file extension of ".vmx" and can be found in:
      /vmfs/volumes/datastore/virtual_machine_directory/virtual_machine_name.vmx
    • Always power off the virtual machine.
    • Determine location of virtual machine datastore and host (or cluster).
    • Make sure you are logged on as a user with the correct permission level to edit the file.

Below is an example list of steps to accomplish this process. Depending on the specific version of ESXi in your environment and other variables some of these steps may vary slightly.

  1. Navigate to the Summary tab for the VM in question, right-click the Storage volume on which the VM is located, and choose "Browse this datastore"
  2. In the "Datastore Browser" window, locate and select the relevant folder for the VM in question
  3. Right-click on the <virtual_machine_name>.vmx file and choose "Download...", selecting a folder on your local machine for the file
  4. Make a backup copy of the .vmx file on your local machine by running the following commands from a Windows Command Prompt in the same folder as the downloaded .vmx file. If your edits break the virtual machine, you can roll back to the original version of the file.
    copy "<virtual_machine_name>.vmx" "<virtual_machine_name>.vmxBACKUP"
  5. Add the necessary configuration to the end of the .vmx file by running the following commands from a Windows Command Prompt in the same folder as the downloaded .vmx file
    copy "<virtual_machine_name>.vmx" temp_file.vmx
    findstr /V /R "^ethernet0.virtualDev.*" temp_file.vmx > "<virtual_machine_name>.vmx"
    echo ethernet0.virtualDev = "vmxnet3" >> "<virtual_machine_name>.vmx"
  6. Upload the edited <virtual_machine_name>.vmx file to the Datastore by selecting the relevant folder for the VM in question in the "Datastore Browser" window, clicking the button for "Upload files to this datastore", and choosing "Upload File..."
  7. Locate the edited <virtual_machine_name>.vmx file from your local machine and select it, acknowledging that existing files of the same name will be overwritten
    Note: Keep the "Datastore Browser" window open, as you will need it again in Step 10
  8. Now that .vmx file is updated, note on which ESXi host the VM in question is located.
  9. From the main vSphere client window, right-click the VM in question in the list of VMs and choose "Remove from Inventory"
  10. Navigate back to the "Datastore Browser" (from the window left open earlier. Otherwise, open the Datastore Browser from another VM's Summary page "Storage" list or the ESXi host's Summary page "Storage" list)
  11. Locate and select the relevant folder for the VM in question
  12. Right-click on the <virtual_machine_name>.vmx file and choose "Add to Inventory".
  13. Step through the "Add to Inventory" wizard, selecting the same host on which you previously noted the VM was located. These steps will ensure that the VM will utilize the updated .vmx file using the network adapter type as "vmxnet3"
  14. On the newly-readded VM you can verify the change by selecting "Edit Settings..", choosing "Network adapter 1" and verifying that the "Adapter Type" section shows "Current adapter: VMXNET 3"

OR

b) If the existing network adapter is configured with a **Manual** (static) MAC address, the administrator can simply remove the existing network adapter and add a new network adapter using the same MAC address.

  1. Verify VM is powered off
  2. Save MAC address of the existing Network adapter
  3. Delete existing Network adapter
  4. Add new Network Adapter using the "VMXNET 3" Adapter type. Use the previously saved MAC address in the manual configuration box.

OR

c) Alternatively, the VMware vSphere PowerCLI can be used to edit the .vmx file with the proper network adapter configuration.

  • The VMware vSphere PowerCLI (set cmdlet) is supported in the following environment:
    • Cisco UC Virtualization Foundation (appears as "Foundation Edition" in vSphere Client)
    • VMware vSphere Standard Edition, Enterprise Edition, or Enterprise Plus Edition
    • Evaluation mode license
  • The VMware vSphere PowerCLI (set cmdlet) is NOT supported in the following environment:
    • Cisco UC Virtualization Hypervisor (appears as "Hypervisor Edition" in vSphere Client)
    • VMware vSphere Hypervisor Edition
  1. Install VMware vSphere PowerCLI (http://www.vmware.com/support/developer/PowerCLI/)
  2. Always power off the virtual machine.
  3. From the Windows "Start" menu select Start -> All Programs -> VMware -> VMware vSphere PowerCLI -> VMware vSphere PowerCLI
  4. Running the following commands, replacing <virtual_machine_host> with the ESXi host machine hostname and <virtual_machine_name> with the actual virtual machine name. Enter credentials when prompted.
    Connect-VIServer <virtual_machine_host>
    get-vm "<virtual_machine_name>" | get-networkadapter | set-networkadapter -type "vmxnet3"
  5. Once the virtual machine is modified, reload it
    Get-View -ViewType VirtualMachine -Filter @{"Name" = "<virtual_machine_name>"} | %{$_.reload()}

A few pointers in procedure a) is that many times you will not find the ethernet0.virtualDev string in the .vmx file, in such case, all you need to do is to actually ADD the line

Go to CUCM Upgrades and Migrations FAQ Content Table

Will the COP files modify my VM settings??

No, none of the COP files that we provide on cisco.com will modify any of the VM settings from your VMs, all those changes (if required) will need to be performed manually via vSphere.

Go to CUCM Upgrades and Migrations FAQ Content Table

My original VM settings have 2 x HDDs, and the new OVAs for my target release only have one, what should I do??

You can upgrade with this configuration and it will be supported, you may need to increase the size of your second HDD to match the specs of the new version OVA.
See How can I add space to my VM HDDs if required??
If you wish to move from the 2 x HDD OVA to a single HDD OVA, you will need to perform a DRS backup/restore. Another alternative would be to use a PCD migration and that would take care of the 2 x HDD to 1 x HDD.

Go to CUCM Upgrades and Migrations FAQ Content Table

I need to increase my CUCM VM capacity to those of a higher capacity OVA, what should I do??

The recommendation has always been that if the HDD capacity is the same between the two OVAs, to just change the vCPU and vRAM to match the specs of the more powerful OVA. If the HDD sizes are different (or differ in number of disks), you would need to perform a DRS backup from the lower capacity VM, and restore in the higher capacity VM.
Even though we have a method to increase the HDD size, it will only increase the /common partition, the rest of them will remain untouched. Be aware we only support UPGRADING the VM specs, we DO NOT SUPPORT DOWNGRADING the VM specs.

Go to CUCM Upgrades and Migrations FAQ Content Table

Can I DRS between different CUCM releases??

No, you cannot. When you create a DRS backup, the file that has the contents for the backup will also contain the EXACT CUCM RELEASE from which it was taken, and it will be used to validate you're restoring on the same CUCM release.

Go to CUCM Upgrades and Migrations FAQ Content Table

Which phone firmware release will work across different CUCM versions??

This is a very common question when it comes to upgrade, as we recommend doing the phone FW upgrade prior to the CUCM upgrade.
Now, which phone FW is supported with my current CUCM version and my target CUCM version??
Well, these days pretty much all the FW releases are compatible, if you go to the downloads page of the FW you want, it will says something like:
9971 SIP IP Phone load signed COP file - Compatible CUCM Versions: 7.1(5)+
Which pretty much guarantees it will work with anything above 7.1(5)

For endpoints that have been around for far more time, like a 7975G, this might show a bit differently, like this, the earliest 9.x FW release for this model (9.0(2)SR1):
7975 SCCP IP Phone Load Compatible CUCM Versions: 5.1.3, 6.0.1, 6.1.3, 6.1.4, 7.0.2, 7.1.2 and above
Still, as you can see it shows some old releases, and 7.1(2)+

Now, if you look at 9.3(1) for the 7975, this DOES change:
7975 SCCP IP Phone Load Signed COP file - Compatible CUCM Versions: 7.1(5)+
I don't have an old CUCM release to test with, but I'm pretty sure this would still work with older releases.

These days, pretty much any phone FW (assuming your CUCM version supports the endpoint) will work across the board, now, this does not mean that you can simply upgrade from FW version A to FW version B, for some of them, there are middle steps required, you should ALWAYS read the README/RNs of the FW version to which you're going to upgrade, to confirm if it's a direct upgrade, or if a middle step is required.

Go to CUCM Upgrades and Migrations FAQ Content Table

Can I use BAT export/import between different CUCM releases??

Well... yes... and no. Usually new releases will add/remove fields in the configuration, this means that your export will either have fields that the new release doesn't have, or missing fields that the new version added.
So, what does this mean to you??
It means you'll need to massage the data as necessary to make it compliant with the format from the target release.

The "easiest" way to do this is to perform an export from both versions and then compare them to add/remove fields as required.

The only way in which this is as simple as doing the export on your original server, don't modify the files at all, and then importing them into the new server, is if you're running the same version on both, or sometimes within the same major release this also might work. This works for sure if you use the same version on both servers.
This is actually the method that is used to migrate the info from a CUCM BE 5K into a standalone CUCM install (6K, 7K, or Enterprise).

Go to CUCM Upgrades and Migrations FAQ Content Table

How can I add space to my VM HDDs if required??

Yes, you can increase the size of the /common partition.
If you wish to increase the size of any of the other partitions, that would require a reinstall on a VM with bigger HDDs, as those are created during initial install only.

Why would you want to do that??
For:

  • Increased logging capacity
  • Used during software upgrade for additional storage

For versions prior to 10.x, a COP file is required for this, ciscocm.vmware-disk-size-reallocation-1.0.cop.sgn
NOTE The version 1.0 might have changed, you can still search for it with the name before 1.0

The above COP file is used for versions:

  • 8.5.1.10000-xx or any higher version starting with 8.5.1.xxxxx
  • 8.6.2.10000-xx or any higher version starting with 8.6.2.xxxxx
  • 9.1.1.10000-xx or any higher version starting with 9.1.1.xxxxx
  • 9.1.2.10000-xx or any higher version starting with 9.1.2.xxxxx

Here is the README for the file, make sure to carefully review it before proceeding with the procedure.

The install for the COP file should be a piece of cake, go to OS admin > Software Upgrades > Install Upgrades > follow wizard.
The COP file will be installed on the active partition, if you upgrade to a release prior to 10.x and want to increase the HDD space again, you'll need to install the COP file again.
Once installed, you can expand as many times as required.
You cannot reduce the size of the disks

For 10.x and above, there is no need for any COP file, the CUCM code already contains this.
A few considerations:

  • Compatible with single and multi-disk OVAs
  • Any VM snapshots (which by the way, we do NOT support) must be removed prior to the procedure
  • You can do this with a powered-on VM, but a reboot is required for the resize to take effect.
  • Only used to increase the size of the disk; decrease in size is NOT ALLOWED

The procedure would be as follows:

  1. Open vSphere and connect to the host, or vCenter.
  2. Right-click the virtual machine.
  3. Click Edit Settings.
  4. Select Virtual Disk.
  5. Increase the size of the disk.
  6. CUCM and vos based guest operating systems require a reboot to recognize the above changes.
  7. DRS backup is suggested to guard against data corruption.

Once you do this, during the reboot, a banner with the message "Hardware setup for server needs reboot for new settings and updates to take effect. Server will reboot and startup will continue after that".
System will unmount the partitions and reboot again to continue with the process.

After the second reboot, the partition table will be reallocated to use the new HDD space. You should see a message Expanding disk. Please wait... during the bootup sequence.

Once the server completely boots, you should see the new disk space if you issue the command show diskusage common

You can watch the procedure on this video: How to upgrade a CUCM/CUPS 8.6 to CUCM/IM&P 11.0

Go to CUCM Upgrades and Migrations FAQ Content Table

How to tell if I'm running a restricted or unrestricted image??

If you're running an unrestricted version, upon login to the CCMadmin page or OS Admin page, you will see the word "Unrestricted" along with the version.
If you're running the restricted (or the old/regular version), you won't see any unrestricted legend, just as it was before the unrestricted version became available.

Go to CUCM Upgrades and Migrations FAQ Content Table

What is the difference between the restricted and the unrestricted image??

Due to export regulations, the unrestricted image has all security and encryption features disabled, besides that, it offers the same capabilities as the restricted image. The restricted image is the old image that has existed since CUCM 5.x and has ALL the security and encryption features enabled.

Go to CUCM Upgrades and Migrations FAQ Content Table

Can I upgrade from an unrestricted version to a restricted version??

No, this is not possible. There is no upgrade path from an unrestricted version to a restricted version. A DRS backup/restore is also not possible as the DRS file will be tagged as coming from an unrestricted deployment, and can only be restored on the same version of an unrestricted image. The only way to go from an unrestricted to a restricted version is to perform a fresh install of the restricted image from the same release you're running, and use the BAT export / import feature to migrate as much information as possible.

Go to CUCM Upgrades and Migrations FAQ Content Table

I accidentally upgraded to an unrestricted version, from a restricted version, can I rollback to restricted??

Yes, this is a very special scenario on which this is possible, and supported. If you performed the upgrade and then later found out you used an unrestricted image, you can use the rollback feature to go back to the restricted version that is sitting in the inactive partition. Any changes done while running the unrestricted version will be lost. Once you perform the rollback, you can then perform the upgrade once again, using the restricted image.

Go to CUCM Upgrades and Migrations FAQ Content Table

I'm trying to install a COP file in CUCM version 9.x and below, and getting some errors, why would that be??

Well, there might be any number of reasons for that:

  • You're using a COP file which is not compatible with your CUCM release
  • The file got corrupted during download and does not match the MD5 checksum
  • The COP file was not downloaded from cisco.com and has been tampered with
  • There were errors when trying to access the file

Or, a new cause which might become very common, is that since the introduction of CUCM 10.x, we changed the RSA keys that are used to sign the ISO and many of the new COP files from cisco.com. CUCM 10.x comes with those keys pre-installed for fresh install, if you're running 9.x and below, you need to install a COP file to add the new RSA key to your system, the COP file you require is: ciscocm.version3-keys.cop.sgn

If you wish to upgrade to 10.x, you'll also need that file. It can be found quite easily on cisco.com under a variety of locations under downloads central, they're all the same, and appear under many products as they all share the same blue-print and use the same file.

Go to CUCM Upgrades and Migrations FAQ Content Table

I'm trying to install a COP file / upgrade CUCM and I'm receiving "No valid upgrade options were found"??

There are several reasons why you might get this message:

  • The COP / ISO file is not compatible with your CUCM release
  • You're pointing to the wrong directory from your TFTP
  • There are problems retrieving all the files from your TFTP

Always make sure the files you're trying to install are compatible with your CUCM release, under certain circumstances the files might be accepted, but error out during the install procedure.

Go to CUCM Upgrades and Migrations FAQ Content Table

Do I need to disable EM prior to the upgrade??

If you're running anything prior to CUCM 10.x, YES, YOU DO. This is in order to avoid any DB changes while the upgrade is taking place.
If you're running 10.x+, then this is no longer necessary, see CSCus10292 No need to Disable Cisco EM service during upgrade, after 10.x

Go to CUCM Upgrades and Migrations FAQ Content Table

Can I upgrade RHEL independently from CUCM??

No, the OS and CUCM are upgraded at the same time (if applicable, not all upgrades modify the underlying RHEL version) during the regular upgrade procedure, priority OS patches/fixes will be released at cisco.com as COP files, otherwise, the bulk of patches/fixes for OS will be included in the regular CUCM MRs.

Go to CUCM Upgrades and Migrations FAQ Content Table

What is a RU (Refresh Upgrade)

A RU is the upgrade on which the underlying RHEL will also be upgraded, for example:

  • CUCM 8 to 9 was a change from RHEL 4 to 5
  • CUCM 9 to 10 is a change from RHEL 5 to 6

Those upgrades take a lot more time as the procedure also takes care of the RHEL upgrade, as well as the CUCM application.
You should plan anywhere between 60 to 120 minutes per node for RUs.

UPDATED 6/7/2018
CUCM 12.0 and related products now use CentOS (64-bits) instead of RHEL.

Go to CUCM Upgrades and Migrations FAQ Content Table

What is the D29 (Drive To 9) program??

The D29 initiative is a program in which we assist you with any questions or concerns you may have when planning your upgrade to CUCM 9.1
Most of the material for the program is here: Migration Resources
Please notice the above link requires partner level to be accessed.

You may reach PDI TA team in case you require further assistance. Please notice we will only assist with technical assistance, if you require CUCM images, that would require a TAC case, if you need assistance with licensing, you need to reach the licensing team.

Go to CUCM Upgrades and Migrations FAQ Content Table

What is the Drive To Collaboration program??

The Drive To Collaboration initiative is a program in which we assist you with any questions or concerns you may have when planning your upgrade to CUCM 10.X
Most of the material for the program is here: Migration Resources
Please notice the above link requires partner level to be accessed.

You may reach PDI TA team in case you require further assistance. Please notice we will only assist with technical assistance, if you require CUCM images, that would require a TAC case, if you need assistance with licensing, you need to reach the licensing team. Go to CUCM Upgrades and Migrations FAQ Content Table

You can also visit Drive To Collaboration site for further information

Go to CUCM Upgrades and Migrations FAQ Content Table

Can I perform the upgrade right now, and switch versions at a later date??

Yes, you can, the caveat is that the DB is migrated during the upgrade procedure, which means that once you switch versions, any changes done between the upgrade and the version switch will be lost.

If the plan includes switching versions in a phased approach, notice that replication will only work between the PUB and the SUBs running the same release, any server that is left in the old version will become read-only due to failure to replicate with the PUB.

Go to CUCM Upgrades and Migrations FAQ Content Table

Back to Unified Communications FAQ
Back to CUCM FAQ

Contact:
Any comments, questions, suggestions, contributions, etc. please send them to javalenc@cisco.com. Please make sure the subject is formatted "UC FAQ <anything else>" as I'll have rules in my mail to match them, otherwise, they'll end up in my spam folder.

Rating: 5.0/5 (27 votes cast)

Personal tools