Upgrading from CUCM 7.1.2.31900-1 to 8.5.1.10000-26

Unanswered Question
Apr 12th, 2012

I have been asked to put together a brief outline of tasks required to achieve an upgrade CUCM from 7.1.2.31900-1 to 8.5.1.10000-26.  I have read pretty much everything that I can find from Cisco and have put together a brief list of tasks that will be required.  I was hoping one of you genius's would cast a quick eye over my list and see if you can spot anything I may have missed please ?

Observations:

There does not appear to be a direct upgrade path for the call manager from version

7.1.2.31900-1 to either 8.5x or 8.6x.
Would need to go to 7.1.(3b)SU2 first.


Prerequisites:

Ensure we have the relevant software feature License prior to upgrade to 8.5
Ensure we have correct versions of ISO Files ready.

CUCM Upgrade procedure:

- Install RAM upgrade to 4GB in both publisher and Subscriber. (Both MCS7825H4)
- Backup CallManager
- Upgrade CUCM Publisher to 7.1.(3b)SU2
- Switch the first node to the upgraded partition
- Test
- Backup CallManager
- Upgrade CUCM Subscriber to 7.1.(3b)SU2
- Switch Subscriber to Upgraded Partition
- Test (Ensure that database replication is functioning between nodes)
- Backup CallManager
- Upgrade Publisher to 8.5.1.10000-26
- Switch the first node to the upgraded partition
- Install Feature License
- Test
- Backup CallManager
- Upgrade Subscriber to 8.5.1.10000-26
- Switch Subscriber to Upgraded Partition
- Test (Ensure that database replication is functioning between nodes)
- Upgrade Unity Express to minimum version of 7.3, preferably 8.5
- Test

- Go home for Tea and Medals!

Any advise or crtiticiscm will be gratefully recieved.  Thanks...

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 5 (6 ratings)
Rob Huffman Thu, 04/12/2012 - 05:29

Hi Nik,

Just to add a couple of comments to the good tips from Ronak (+5 "R")

If you ordered the 8.5 upgrade DVD's from Cisco via PUT (Product Upgrade Tool)

the PAK would be included and can be submitted to receive the Software feature

license. We always try to secure the actual "build" DVD's for CUCM versions rather

than the upgrade .iso's just in case you ever need them for DRS.

PUT

http://tools.cisco.com/gct/Upgrade/jsp/productUpgrade.jsp

The other thing I would probably do is to do your CUE upgrade ahead of time just to

lessen the load on the night of the CUCM upgrade. CUE 7.3 and 8.5 are both backward

compatible for use with CUCM 7.x

Table 2: Cisco Unity Express: Unified CM Versions

Cisco Unity Express Versions
2.0.x2.1.x2.2.x2.3.12.3.33.0.x3.1.13.1.23.2.13.2.27.0.x7.1.x7.2, 8.07.3, 8.57.4, 8.6
2.3.22.3.4
Cisco Unified Communications Manager Versions3.3(3), 3.3(4), 4.0(1),
4.0(2)
4.1(2),
4.1(3)
4.2(1),
4.2(3)
4.3(1), 4.3(2)
5.0(1), 5.0(2), 5.0(3),
5.0(4)
5.1(1), 5.1(2),
5.1(3)
6.0(1)
6.1
7.x
8.0
8.5
8.6
NOTE: CUCM version 5.1(1) does not interoperate with CUE version 3.2.x. Before version 5.0, Cisco Unified Communications Manager was known as Cisco Unified CallManager.

http://www.cisco.com/en/US/docs/voice_ip_comm/unity_exp/compatibility/cuecomp.htm

And lastly, look into upgrading your phone firmware to the version for your 8.5 build ahead of

time. The phone firmware portion of these upgrades can (and has) tripped many people up

over the years.

Cheers! And best of luck!

Rob

nik.warren Thu, 04/12/2012 - 06:07

Thanks both of you for your time and comments.  Very usefull.  Do you think it would be advisable to do the upgrade to CUCCM 7.1.(3b)SU2 on a seperate occasion, again to lighten the load on the 8.5 upgrade evening / weekend ?  We do have CUCCX 7.0(1)SR5_Build504, and I believe that this is compatible with CUCM 71.1(3b)SU2 anyway.

Rob Huffman Thu, 04/12/2012 - 06:14

Hey Nik,

You are most welcome

I'm a pretty paranoid person so I would separate these tasks if at all possible

just to mitigate the risks (bugs etc.). So I would make the jump to 7.1(3b)su2

during a different maintenance window.

Cheers!

Rob

Robert Thomas Thu, 04/12/2012 - 06:48

The only criticism I might have is the test periods you have in between the PUB and SUB switchovers. Since the Applications are running distinct versions at that point, you might find some inconsistencies and weird behaviour with your testing at that point, but it can depend on what you are actually thinking for your test best.

I would roll out a large set of test once both servers have been migrated to the new version, and then give myself a Window for roll back. I would not actively troubleshoot anything weird that might show up in 7.1.3 as we are just passing by it, without intention to stay.

Finally keep in mind your Jtapi Client!!, You might need to do a Resync in your UCCX if the Jtapi client happen to upgrade revision between your 7.1,2 and 7.1..3 CUCM.

Gordon Ross Thu, 04/12/2012 - 07:10

Robert Thomas wrote:

The only criticism I might have is the test periods you have in between the PUB and SUB switchovers. Since the Applications are running distinct versions at that point, you might find some inconsistencies and weird behaviour with your testing at that point

BIt of an understatement ;-)

With the PUB & SUB on different versions of software, they ain't gonna be talking to each other. You want to minimise the time spent with the cluster in this state, so I wouldn't have much testing in there. The only "test" I'd have, is making sure the PUB comes up cleanly on the new version of software. As soon as it's up, get that SUB switching versions.

Also, that backup you've got scheduled between the PUB & SUB switches will only work for the PUB. I'd skip this entirely. At this stage, you shouldn't be making any DB changes to your system, so a backup is not needed.

GTG

Gordon Ross Thu, 04/12/2012 - 07:14

If I'm reading your agena correctly, you're going to install the software on the SUB after you've switched versions on the PUB. I'd change this and do the SUB install as soon as the PUB install has finished. Then once both installs have finished, you can do the switch version on the PUB, followed by the SUB.

A small suggestion: After you've done the switch version on the PUB, use RTMT to monitor the PUB's CPU utilisation. Once the utilisation drops to normal, then switch version on the SUB.

GTG

Rob Huffman Thu, 04/12/2012 - 07:29

Excellent points "G-Man" and Robert! +5 each for these great observations

Cheers!

Rob

asafayan Tue, 04/24/2012 - 16:14

Hi Rob and company,

I see  no mention of the COP file.  I find myself in the exact same version upgrade situation as Nik and my understanding is that I'll have to install a COP file as follows:

1.  Install COP v1.1 on all existing nodes in 7.1.2.31900-1 cluster

2.  Upgrade cluster to 8.0(3a)SU3

3.  Install Feature License

4.  Upgrade cluster to 8.6(2a)SU1

Does that sound correctomundo?

Thanks,

Amir

clileikis Tue, 04/24/2012 - 16:26

Hi Amir,

The cop "refresh upgrade" only applies to 8.6, not 8.5.

HTH,

Chris

asafayan Tue, 05/01/2012 - 10:16

Hi Chris,

Thanks for the clarification. The initial poster was upgrading to CUCM 8.5 and I'm going to CUCM 8.6. 

Does my basic process sound correct when upgrading to CUCM 8.6 ?

1.  Install COP v1.1 on all existing nodes in 7.1.2.31900-1 cluster

2.  Upgrade cluster to 8.0(3a)SU3

3.  Install Feature License

4.  Upgrade cluster to 8.6(2a)SU1

Thanks!

Amir

Gordon Ross Tue, 05/01/2012 - 10:20

I'd do the COP *after* the upgrade to 8.0

The COP modifies the installer component within CUCM, so installing it and then installing 8.0 could "undo" that modification.

GTG

Actions

Login or Register to take actions

This Discussion

Posted April 12, 2012 at 4:46 AM
Stats:
Replies:12 Avg. Rating:5
Views:1072 Votes:0
Shares:0
Tags: No tags.

Discussions Leaderboard

Rank Username Points
1 21,026
2 15,047
3 10,314
4 7,999
5 4,856
Rank Username Points
135
90
72
66
55