Upgrade to CUCM 6.1(5) from 6.1x or 6.2x possible?

[andy_vvc2]

Hi all,

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 !!!!!

http://www.cisco.com/en/US/customer/docs/voice_ip_comm/cucm/rel_notes/6_1_5/cucm-rel_note-615.html#wp782718

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? 

Rgds

[Rob Huffman]

Hi Andy,

The two places that have the most accurate upgrade info

are the Compatibility Matrix and the "Download Files" section

Many times the release notes seem to have a bit of a "cut & paste"

type of accuracy.

It's definitely CUCM 6.1(3)

Cheers!

Rob

[andy_vvc2]

Cheers Rob - that would suggest that our test lab server v6.1(1) needs THREE updates. One to 6.1(2), then to 6.1(3x)

then to 6.1(5)...

Our Production servers running 6.1(2) need to be upgraded to 6.1(3x) then to 6.1(5).

This seems like a horrible way of working. Is there any reason behind this odd upgrade path? Our test lab server is an older build because the drives failed, so i had to reinstall it from the 6.1(1) DVDs that we have. However, the production servers have not caused us any problems (they have worked flawlessly and so have not been upgraded at any point other than SCCP firmware files etc). Did Cisco phase out support for 6.1(2), or do they just not produce upgrade files that allow upgrades from older builds...? This creates something of a headache to achieve the latest 6.1(5) upgrade....needing two upgrades on our production servers. They don't do this with IOS releases (thank goodness!)

The doco suggests that the two files (once merged into an ISO on DVD) can be used to upgrade from 6.1(1) upwards. If this isnt the case, our upgrade path will be painful....

[Rob Huffman · Accepted solution]

Hey Andy,

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.

Cheers!

Huff

[David Hailey · Accepted solution]

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.

Hailey

Please rate helpful posts!

[andy_vvc2]

Thanks guys, input very much appreciated. I think we are preparing for a two-phase upgrade doh! 

Can i ask, with regards the upgrade, the ISO is pushed to the second 'partition' on the server during the upgrade.  This is done for all four servers (we have 1xPub, 3xSubs one of which is on a remote site).  Once pushed, the 'Upgrade' lies dormant and unused until i tell the Pub (then the subs) to restart and 'switch' partitions.

At what point does the 'switch' reboot do anything more than simply boot the new ISO image? Does it do more than this - ie it imports database settings etc during the reboot before it launches from the alternate partition with the newer 6.1(3) image?   I'm struggling to see why a full ISO of 6.1(5) can't simply be installed and used....unless i am correct about somekind of database settings being imported...?

One last question - of the various releases of 6.1(3) which one ought we to be using?  6.1(3), 6.1(3a) and 6.1(3b) are all possible from 6.1(1) and 6.1(2). I assume 6.1(3b) is the most stable and incorporates bugfixes etc over-and-above the 6.1(3) and 6.1(3a) releases?

Thanks one again for the support. You are correct Rob, we are lucky this isnt the old Windows 20hr+ upgrade version 

[Rob Huffman · Accepted solution]

Hi Andy,

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

Guide;

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)

Cheers!

Huff

[David Hailey · Accepted solution]

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.

Hailey

Please rate helpful posts!

[andy_vvc2]

Thanks for the upates guys. Looks like an upgrade to 6.1(3b) and then a day or two later a second upgrade to 6.1(5) is what my company have a preference for. They will review the 7.x and 8.x upgrade path seperately and (most likely) buy new hardware etc etc and make a full upgrade project of that next year.

I have one more question. Looking at the matrix's here: http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/compat/ccmcompmatr.html  I note that the 'Device Defaults' for version 6.1(3a) that are listed (I will use 6.1 3b but that isnt listed in the Device Defaults) show that our 7960, 7935, 7936 phones will get upgraded by a few small version revisions (ie 7960 jumps from 8-0-8 to 8-0-9 etc).  Two phones will be downgraded - 7921 and 7961 (or these only the 7921 bothers me as we have JUST gone to 1-4-3 to overcome audio roaming issues lol!).  I take it that after upgrading the inactive partitions on the PUB and SUBS (and then restarting them with the "switch" option in the correct order), i should then issue a deice restart for all our phones?

I will do this by page (100 devices at a time) and will refresh the page to see which go to 'not registered' and then to 'registered' after they are patched. Simple enough.  I will then need to manually install the 7921 firmware (again)

When we then migrate to v6.1(5), it looks like i have several phone types that will be upgradeded - thus i will again need to do device restarts (100 per page).  We have 1100 phones so this could be....fun.....  will manually install the 7921 firmware ....again  lol

Does this sound like the correct way to handle the upgrade?  I will ensure that my company leverage their Cisco Account Manager to get a Cisco resource to review the upgrade plan that i put together. We will also get TAC standing by incase there ae any issues. (I have a test lab to upgrade first so i can test the install etc)  To be honest, with the excellent advice on NetPro i think my plan might be better than Cisco's  

Thanks in advance!

[Rob Huffman · Accepted solution]

Hey Andy,

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.

Cheers!

Rob

Please support CSC Helps Haiti

https://supportforums.cisco.com/docs/DOC-8895

https://supportforums.cisco.com/docs/DOC-8727

[andy_vvc2]

Thanks Rob.  Does CUCM force firmware to phones if the phone are running *newer* versions of the firmware?

I assume it doesnt, therefore if i upgrade all the phones first to the 6.1(5) based firmware as you suggest (via seperate manual installs to the tftp server) that will mean i can restart these devices weeks before the main change and get them on the latest firmware. Then, when i upgrade to CUCM 6.1(3b) and a week later to 6.1(5) no firmware will be pushed to the phones...?

I'm never certain if IP phones will pickup and install older firmware if a CUCM server is upgraded to a version with *older* firmware files....?

Rgds

[Rob Huffman · Accepted solution]

Hey Andy,

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

Cheers!

Rob

[David Hailey · Accepted solution]

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.

Hailey

Please rate helpful posts!

[andy_vvc2]

Thanks again guys!

It seems that our Publisher and our London-based SUB are the TFTP servers. So i may try the following:

1 - upload the 6.1(5) firmware manually to both tftp servers for the IP phone types that we have.

2 - restart the phones over the course of one night, ensuring they reload and pick up the new firmware (100 devices at a time)

3 - during the later "upgrades" before i switch versions, i will disable the tftp service on both machines

4 - in theory the upgrade switch (when i start it off on the PUB) will keep the tftp service disabled

5 - once all the servers are restarted with the switch option, i should be able to manually over-type the values in the 'Device Defaults' page on both tftp servers to use the 6.1(5) firmware (manually uploaded)

6 - restarting tftp service should then return me back to status-quo, but running on the newer version of 6.1. The restart wont trigger any IP phone firmware updates because they will already be running the version i have manually entered into the Device Defaults (6.13b upgade). When we do 6.1(5) the Device Defaults will match my manual uploads anyway.

Only a few issues.  I have no idea if an upgrade to CUCM will KEEP the manually upgraded firmware files...i may need to re-upload them to the tftp servers. Im also less than happy that there is no drop-down menu on the Device Defaults page. This, coupled with the fact that the firmware filenames arent always the same as the Device Defaults name is rather annoying! 

I shall be writing up a formal upgrade plan for the company. Once the CUCM suite is successfully upgraded, i will upload the plan to NetPro - it may be of use to others. (I will get some nods to Huff and Hailey in there)

One thing im not certan about - where am i checking to see if the IP phones have a 'failover' subscriber set? I can locate this on the IP phones themselves (Device Config > Unified CM Config > Unified CM 1 and Unified CM 2 IP addresses). We seem to use SUB 1 as ACTIVE, and SUB2 as STANDBY. Im not certain where these settings are set within CUCM though...?

Cheers

[Aaron Harrison]

Hi

A couple of comments:

Re step 3) - my understanding is that your config is migrated to the other partition when you execute the upgrade, not the switch... So if TFTP is running then, it will run when you switch. If it's not running when you run the upgrade, I'd expect it to not run when you switch.

Checking failover - basically each phone has a 'Device Pool' assigned. Each 'Device Pool' has a 'CallManager Group'. The 'CallManager Group' lists the CCMs that will be used in order. Device Pools/CM Groups are under the 'System' menu in CCMAdmin.

Regards

Aaron