It seems we will need to upgrade our CUCM servers from 6.1(2) to 6.1(5) to overcome a DoS vulnerability with older releases of CUCM.
Reading the info from our Security Team, it seems that ALL older versions of CUCM are vulnerable, and that 6.1(5) is needed as this addresses the vulnerability.
However, we are running on 6.1(2) because we have had no vulnerability alerts for any services we run to necessitate an earlier upgrade. (There was a CAPF vulnerability, but we have the service disabled).
My concern is that it doesn't appear possible to upgrade from 6.1(2) straight to the new 6.1(5) release
The upgrade matrix is here: http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/compat/ccmcompmatr.html
However - there is a section in this document, which suggests an upgrade from 6.1x upwards IS possible !!!!!
So which is corect? I have just cancelled my download of the part 1 and 2 upgrade files because they state (on the damn download page) that they only work with 6.1(3x) upwards ! ! !
Which Cisco statement is correct?
To add to what Rob has said:
The phones will use the device defaults to load firmware on the upgrade whether it is an upgrade or downgrade. Here are 2 options that may work but you would want to validate in your lab environment before banking on it:
1) You can use BAT to hardcode the phone load version on each model of phone that you have. If the firmware is upgraded from 6.1(3) to 6.1(5) then the phones would use the lower version of code you've hardcoded on each device.
2) When you switch versions on the Publisher to 6.1(3) (assuming it is the TFTP server or you have a separate non-call processing node that is a TFTP server), load the latest firmware (if needed) on the server and set the device defaults before you switch versions on the Subscriber(s). As long as the TFTP server has the correct firmware version on it, the phones should simply failover to their secondary and then failback when the switch is complete.
The other option that you have is upgrade to 6.1(3) code and then upgrade to the 6.1(5) firmware loads while on 6.1(3). From there, when you upgrade to 6.1(5) - you'll be ready to go.
Please rate helpful posts!
Excellent question my friend
I have not tried this "exact" scenario, but I'm pretty sure that the
phones will try to use whatever is listed in the Device Defaults
page, even if this means a Firmware downgrade (as you nicely noted)
The nice thing here is that you have a lab to experiment a bit with this, I think
that if the TFTP service was kept unavailable during the initial CUCM switch/version
for 6.1(3b) you would have a chance to set the Device Defaults page accordingly to reflect
the "final" Firmware versions (that will be used in 6.1(5)). If this isn't desirable, then you will still
be able to do these in two slices; 1- pre 6.1(3b) & 1- pre 6.1(5) which will still save a
ton of pain on the night of
Just one thing here that I can think of
The phones will start upgrading their Firmware when the CUCM
boxes are restarted during the Switch version process, so you will
in essence be upgrading all 1100 phones at the same time. Your best bet
IMO is to upgrade the Firmware prior to doing the CUCM upgrade, this saves
all this extra time/trouble on the night of the actual change. My vote would
be to upgrade the phones right to the Firmware that will be used on 6.1(5).
I'm not sure what Firmware is used for 7941/42/45 etc. but we'll need to check to see
if it's 8.5(3) which may require a two-step approach.
Please support CSC Helps Haiti
Rob pretty much gave you the rundown right there. So, that's that. Here's my advice on version. 6.1(3b) has been very stable for me at a number of customer sites. Personally, I would get to that version and then plan a move to 7.1(3b)SU2. As 8.0 comes out, 6x will start to phase into the "legacy" phase (not that it won't work and be used by many) but on 7x you'll be set up for new features and such as well as be in a position to less painfully transition to 8.x whenever it is fully vetted and stable...which may be a while.
Please rate helpful posts!
Good stuff my friend
These type of upgrades will always be neccessary when we don't move
quickly down the "Cisco" upgrade path. But it's a fine line because we don't want
all the bugs that are sometimes present in the "latest & greatest" versions.
For question #1;
Yes, the new vesrion is built on the inactive partition and just sits there
until instructed to switch versions. here is an example from the 6.x SRND
A cluster can be upgraded to Unified CM 6.x without impacting the services. Two different versions (releases) of Unified CM may be on the same server, one in the active partition and the other in the inactive partition. All services and devices use the Unified CM version in the active partition for all Unified CM functionality. During the upgrade process, the cluster operations continue using its current release of Unified CM in the active partition, while the upgrade version gets installed in the inactive partition. Once the upgrade process is completed, the servers can be rebooted to switch the inactive partition to the active partition, thus running the new version of Unified CM.
Upgrading from Unified CM 6.x to Unified CM 6.x
The 1:1 redundancy scheme enables you to upgrade the cluster using the following method:
Step 1 Install the new version of Unified CM on the publisher. Do not reboot.
Step 2 Install the new version of Unified CM on all subscribers simultaneously. Do not reboot.
Step 3 Reboot only the publisher. Switch to the new version of Unified CM and allow some time for the database to initialize.
Step 4 Reboot the TFTP server(s) one at a time. Switch to the new version of Unified CM and wait for the configuration files to be rebuilt before upgrading any further servers in the cluster.
Step 5 Reboot the dedicated music on hold (MoH) server(s) one at a time. Switch to the new version of Unified CM.
Step 6 Reboot the backup subscriber(s) one at a time. Switch to the new version of Unified CM. This step might impact some users if 50/50 load balancing is implemented.
Step 7 Fail-over the devices from the primary subscribers to their backups.
Step 8 Reboot the primary subscriber(s) one at a time. Switch to the new version of Unified CM.
With this upgrade method, there is no period (except for the failover period) when devices are registered to subscriber servers that are running different versions of the Unified CM software.
Note When upgrading from Unified CM 6.0 to Unified CM 6.1 or later releases, any changes made to user-facing call processing features in the active partition of the subscriber's database will be migrated to the new version of the database. Any other database changes made in the active partition of the publisher's database will not be migrated to the new version of the database.
For question #2;
The upgrade does import dB settings
For question #3;
6.1(3b) is likely your best bet here. Take some time to review the "open" caveats related
to each version to make sure that there is not something waiting to bite you in the (you know what)
6.1(3) has actually been considered to be a very stable release for CUCM 6x. Of course, recently there have been
some ES and etc. that have lead to 6.1(4) and not too long thereafter 6.1(5). So, the upgrade path that Rob told you is correct and basically it has to do with a "path of least resistance" (if you will) in terms of making sure the proper ES patches get applied wholly but efficiently for CUCM. Hence, the upgrade path is what it is.
Please rate helpful posts!
I think we all feel your pain here my friend
I'll let someone else comment on why these upgrade paths
are what they are, but the bottom line is the same. For the lab,
box can go from 6.1(1) directly to 6.1(3) and then 6.1(5) so only
two steps. And of course you know the path for your Production boxes.
The upside here is that these upgrades are not 20 hours each
like the "old" windows upgrades, more like a couple of hours. With the ability
to upgrade during business hours and switch-versions after hours it
shouldn't be too bad. The .iso files from CCO can be used for these
upgrades so you don't have to order the media.