cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1945
Views
15
Helpful
6
Replies

Upgrade from 7.1.5 to 8.6.2

Raymond Choi
Level 1
Level 1

Hello,

We're currently in the process of planning our CUCM 7.1.5 upgrade to 8.6.2 however I've got a few concerns with upgrade procedure in the Cisco documentation and am hoping someone can clarify.

Current version - 7.1.5.31900-3

New Version - 8.6.2.22900-9

1 x Pub

4 x Sub

1 x TFTP

We're looking to keep the downtime on the phones to a minimum and have the following procedure in mind, the firmware on the phones have already been updated to the packaged firmware version in 8.6:

  1. Upgrade Pub to 8.6.(2a)SU2 and do not switch versions
  2. Upgrade TFTP and remainder of the Subs without switching versions
  3. Once all upgrade files have been installed on the inactive partitions, perform a 'switch versions' starting with the Pub
  4. Perform 'switch versions' on TFTP and Subs

The concerns we have are:

  • Before the switch versions' takes place, will there be any issues that the Linux OS has been upgraded from REL4 and REL5 and the CUCM is still running 7.1.5 in the active partition? Will this cause call-processing issues?
  • What would be the longest period that call-processing and device registration will be unavailable during this upgrade? Only when the phones re-home back to primary Subs?
  • In the 'cucm-readme-862asu2.pdf' document, it states in the Important notes that "...register all devices to servers that are running the same versions of Cisco Unified Communications Manager software. Make sure that you register all devices to the backup Cisco Unified Communications Manager server or to the primary Cisco Unified Communications Manager server, but not to both the backup and primary servers". Will this be an issue with the implementation procedure outlined above?
  • Will a cluster reboot of the phones be required at the 'Enterprise Parameter' level once the cluster has been upgraded to 8.6? I saw a comment somewhere about this being a requirement.

Any suggestions or comments will be greatly appreciated.

Regards,

Ray

3 Accepted Solutions

Accepted Solutions

Jonathan Schulenberg
Hall of Fame
Hall of Fame

I'm not sure that hopping through 8.5.x buys you anything except more work here. The compability matrix shows the version you listed to be a single-hop path.

Before the switch versions' takes place, will there be any issues that the Linux OS has been upgraded from REL4 and REL5 and the CUCM is still running 7.1.5 in the active partition? Will this cause call-processing issues?

The problem in this case is that you're looking at a refresh upgrade. The node must reboot to the Anaconda installer to install RHEL5. Because of this each node will be offline for most of the upgrade you can't separate the upgrade from switching version process; it happens all at once. Here's how it'll play out:

  1. DRS backup.
  2. Install refresh upgrade COP on all nodes.
  3. Start administrative change lockout.
  4. Perform upgrade on publisher (~3.5 hours or longer on MCS hardware)
  5. Perform upgrade of TFTP and secondary subscribers. Additional comments about the subscribers in the next question. (~3 hours)
  6. Ensure that the database is in sync on the now-upgraded nodes. (~30-60 minutes)
  7. Perform upgrade on primary subscribers at the same time. This should be the first step that is user-impacting. (~3 hours)
    1. Phones will failover to secondary node and then reboot for firmware upgrades. If you have Peer Firmware Filesharing enabled on them this will only take ~20 minutes, excluding WAN delay.
    2. Phones will then register.
    3. Gateways/trunks, if properly configured, should also failover. The cluster should effectively be running on the new version now.
  8. Ensure the database is in sync once the primary subscribers have upgraded. Phones, gateways and trunks will likely fall back before the database syncs so be prepared for a few small oddities during this period.
  9. Take a new backup.

What would be the longest period that call-processing and device registration will be unavailable during this upgrade? Only when the phones re-home back to primary Subs?

In the 'cucm-readme-862asu2.pdf' document, it states in the Important notes that "...register all devices to servers that are running the same versions of Cisco Unified Communications Manager software. Make sure that you register all devices to the backup Cisco Unified Communications Manager server or to the primary Cisco Unified Communications Manager server, but not to both the backup and primary servers". Will this be an issue with the implementation procedure outlined above?

This is also covered in the SRND under Call Processing Subscriber Redundancy. Nodes can only form an SDL link with other nodes running the same version. If you do not have a clean 1:1 primary/secondary CallManager Group configuration this will result in the cluster being fragmented during the upgrade. Here's an example:

  • CMG A uses subscriber 1 for primary and 2 for secondary.
  • CMG B users subscriber 3 for primary and 2 for secondary.
  • Subscriber 2 capacity is only sufficient to handle one node failing over to it, not both. This is a 2:1 design.
  • You upgrade subscriber 2 first, then subscriber 1. When the phones failover to subscriber two they are now on the new version.
  • The phones on subscriber three are still on the old version and you cannot upgrade this node until the phones from CMG A have returned to node 1.
  • Phones on 3 three can call each other (old version). Phones on subscriber 2 can call each other (new version). Phones cannot call between nodes though; the SDL link is down.

The recommendation is to always keep 1:1 CMG designs (i.e. CMG A has subscribers 1 and 2, CMG B has subscribers 3 and 4). In this design you can upgrade both of the secondary subscribers together without anyone noticing. Once that's complete you start the upgrade of both the primary subscribers forcing all phones/gateways/trunks to failover to their secondary nodes in a coordinated fashion. Essentially you're doing a Side A/Side B "flip the switch."

So, what will the outage to phones be? If you're following the 1:1 design it should only be as long as it takes the phone to upgrade firmware and re-register to the secondary subscriber. A subscriber can complete ~100 device registrations per second so take ~20 minutes for firmware upgrade and tack on a few minutes to account for WAN delay and registration processing. There will be a secondary blip when phones fallback to their primary node but this only take a moment.

Will a cluster reboot of the phones be required at the 'Enterprise Parameter' level once the cluster has been upgraded to 8.6? I saw a comment somewhere about this being a requirement.

Usually not. You can use this as a trick to force a reboot to notice the new firmware on the TFTP server. Just keep a phone near you and see if it auto-upgrades its firmware when failing over. If not just force a reboot of the devices, optionally in smaller chunks (e.g. by device pool).

Please remember to rate helpful responses and identify helpful or correct answers.

View solution in original post

allan.thomas
Level 8
Level 8

Hi Raymond,

I would agree with Jonathan in this case +5, I don't see any benefit from doing a two step installation. There is no specific caveat to state that you shouldn't upgrade directly 8.6.2, as Jonathan mentioned the actual upgrade path indicates that a direct upgrade is supported for 7.1.5. In fact the 8.6.2 release notes stipulates that if upgrading from 8.5 or earlier you need to ensure you install the refresh upgrade cop file as below:

Caution For both restricted and unrestricted upgrades from an 8.5(x) or earlier release to an 8.6(x) release, this patch (COP file) must be applied prior to initiating the upgrade. Before you upgrade from compatible versions of Unified CM, install the COP file named ciscocm.refresh_upgrade_v1.0.cop.sgn that you can find under:

Cisco Unified Communications Manager Version 8.6>Unified Communications Manager / CallManager / Cisco Unity Connection Utilities>COP-Files

Additionally there is no switchover as Jonathan mentioned it all happens at the same time for both Publisher and Subscriber as there multiple upgrades, the only option is to proceed with the switchover in order to complete the upgrade. Thus it is imperative that a DRS is taken prior to commencing the upgrade, also verify that you have good replication status too.

I have upgraded to 8.6.2 on both new and existing hardware, and I've certainly never had an issue with the upgrade to 8.6.2 on existing hardware providing it adheres to guidelines, other than I had not really anticipated the duration for then upgrade due the RH installation, and firmware updates to the bios and subsequent controllers. I would certainly follow Jonathan's steps particularly if you want to minimise disruption throughout the upgrade, but bear in mind the restriction calling between nodes.

Regards
Allan

Sent from Cisco Technical Support iPad App

View solution in original post

Robert Thomas
Level 7
Level 7

Hello Raymond,

It's a matter of personnal choice, but the reason I recommend you to go through 8.5 is because multiple caveats specifically for the 7.1.5, to 8.6 scenario. The documentation is correct in regards that is supported, you can even upgrade from 7.0.2 to 8.6, but personally I don't think it's a good idea.

CSCtq88096

Tomcat failed to start after upgrade from 7.1.5 to 8.6.2

CSCtx96816

3905 devpack test: "Softkey Template" is missed in CUCM 7.1.5 and 8.6.2

CSCtj90316

PMR 81134 CUCM Database assert failure after upgrade from 7.1(5)

CSCtq18720

Bulk Administration file/log migration of RU from 7.1.5 to 8.6.1

CSCtv21624

Upgrade from 7.1.5.10000-12 Restricted results in DRS unable to Restore

You can certantly do the upgrade direct to take some time, but I think  you should be aware of this caveats.

View solution in original post

6 Replies 6

Robert Thomas
Level 7
Level 7

I would not attempt to upgrade directly from 715 to 8.6, rather 7.1.5, 8.5 and then refresh upgrade to 8.6

Sent from Cisco Technical Support iPhone App

Jonathan Schulenberg
Hall of Fame
Hall of Fame

I'm not sure that hopping through 8.5.x buys you anything except more work here. The compability matrix shows the version you listed to be a single-hop path.

Before the switch versions' takes place, will there be any issues that the Linux OS has been upgraded from REL4 and REL5 and the CUCM is still running 7.1.5 in the active partition? Will this cause call-processing issues?

The problem in this case is that you're looking at a refresh upgrade. The node must reboot to the Anaconda installer to install RHEL5. Because of this each node will be offline for most of the upgrade you can't separate the upgrade from switching version process; it happens all at once. Here's how it'll play out:

  1. DRS backup.
  2. Install refresh upgrade COP on all nodes.
  3. Start administrative change lockout.
  4. Perform upgrade on publisher (~3.5 hours or longer on MCS hardware)
  5. Perform upgrade of TFTP and secondary subscribers. Additional comments about the subscribers in the next question. (~3 hours)
  6. Ensure that the database is in sync on the now-upgraded nodes. (~30-60 minutes)
  7. Perform upgrade on primary subscribers at the same time. This should be the first step that is user-impacting. (~3 hours)
    1. Phones will failover to secondary node and then reboot for firmware upgrades. If you have Peer Firmware Filesharing enabled on them this will only take ~20 minutes, excluding WAN delay.
    2. Phones will then register.
    3. Gateways/trunks, if properly configured, should also failover. The cluster should effectively be running on the new version now.
  8. Ensure the database is in sync once the primary subscribers have upgraded. Phones, gateways and trunks will likely fall back before the database syncs so be prepared for a few small oddities during this period.
  9. Take a new backup.

What would be the longest period that call-processing and device registration will be unavailable during this upgrade? Only when the phones re-home back to primary Subs?

In the 'cucm-readme-862asu2.pdf' document, it states in the Important notes that "...register all devices to servers that are running the same versions of Cisco Unified Communications Manager software. Make sure that you register all devices to the backup Cisco Unified Communications Manager server or to the primary Cisco Unified Communications Manager server, but not to both the backup and primary servers". Will this be an issue with the implementation procedure outlined above?

This is also covered in the SRND under Call Processing Subscriber Redundancy. Nodes can only form an SDL link with other nodes running the same version. If you do not have a clean 1:1 primary/secondary CallManager Group configuration this will result in the cluster being fragmented during the upgrade. Here's an example:

  • CMG A uses subscriber 1 for primary and 2 for secondary.
  • CMG B users subscriber 3 for primary and 2 for secondary.
  • Subscriber 2 capacity is only sufficient to handle one node failing over to it, not both. This is a 2:1 design.
  • You upgrade subscriber 2 first, then subscriber 1. When the phones failover to subscriber two they are now on the new version.
  • The phones on subscriber three are still on the old version and you cannot upgrade this node until the phones from CMG A have returned to node 1.
  • Phones on 3 three can call each other (old version). Phones on subscriber 2 can call each other (new version). Phones cannot call between nodes though; the SDL link is down.

The recommendation is to always keep 1:1 CMG designs (i.e. CMG A has subscribers 1 and 2, CMG B has subscribers 3 and 4). In this design you can upgrade both of the secondary subscribers together without anyone noticing. Once that's complete you start the upgrade of both the primary subscribers forcing all phones/gateways/trunks to failover to their secondary nodes in a coordinated fashion. Essentially you're doing a Side A/Side B "flip the switch."

So, what will the outage to phones be? If you're following the 1:1 design it should only be as long as it takes the phone to upgrade firmware and re-register to the secondary subscriber. A subscriber can complete ~100 device registrations per second so take ~20 minutes for firmware upgrade and tack on a few minutes to account for WAN delay and registration processing. There will be a secondary blip when phones fallback to their primary node but this only take a moment.

Will a cluster reboot of the phones be required at the 'Enterprise Parameter' level once the cluster has been upgraded to 8.6? I saw a comment somewhere about this being a requirement.

Usually not. You can use this as a trick to force a reboot to notice the new firmware on the TFTP server. Just keep a phone near you and see if it auto-upgrades its firmware when failing over. If not just force a reboot of the devices, optionally in smaller chunks (e.g. by device pool).

Please remember to rate helpful responses and identify helpful or correct answers.

aos5tacid
Level 1
Level 1

You can't go straight to 8.6 because the kernel change from 8.5 to 8.6 you have to go through 8.5 first.

Sent from Cisco Technical Support iPhone App

allan.thomas
Level 8
Level 8

Hi Raymond,

I would agree with Jonathan in this case +5, I don't see any benefit from doing a two step installation. There is no specific caveat to state that you shouldn't upgrade directly 8.6.2, as Jonathan mentioned the actual upgrade path indicates that a direct upgrade is supported for 7.1.5. In fact the 8.6.2 release notes stipulates that if upgrading from 8.5 or earlier you need to ensure you install the refresh upgrade cop file as below:

Caution For both restricted and unrestricted upgrades from an 8.5(x) or earlier release to an 8.6(x) release, this patch (COP file) must be applied prior to initiating the upgrade. Before you upgrade from compatible versions of Unified CM, install the COP file named ciscocm.refresh_upgrade_v1.0.cop.sgn that you can find under:

Cisco Unified Communications Manager Version 8.6>Unified Communications Manager / CallManager / Cisco Unity Connection Utilities>COP-Files

Additionally there is no switchover as Jonathan mentioned it all happens at the same time for both Publisher and Subscriber as there multiple upgrades, the only option is to proceed with the switchover in order to complete the upgrade. Thus it is imperative that a DRS is taken prior to commencing the upgrade, also verify that you have good replication status too.

I have upgraded to 8.6.2 on both new and existing hardware, and I've certainly never had an issue with the upgrade to 8.6.2 on existing hardware providing it adheres to guidelines, other than I had not really anticipated the duration for then upgrade due the RH installation, and firmware updates to the bios and subsequent controllers. I would certainly follow Jonathan's steps particularly if you want to minimise disruption throughout the upgrade, but bear in mind the restriction calling between nodes.

Regards
Allan

Sent from Cisco Technical Support iPad App

Robert Thomas
Level 7
Level 7

Hello Raymond,

It's a matter of personnal choice, but the reason I recommend you to go through 8.5 is because multiple caveats specifically for the 7.1.5, to 8.6 scenario. The documentation is correct in regards that is supported, you can even upgrade from 7.0.2 to 8.6, but personally I don't think it's a good idea.

CSCtq88096

Tomcat failed to start after upgrade from 7.1.5 to 8.6.2

CSCtx96816

3905 devpack test: "Softkey Template" is missed in CUCM 7.1.5 and 8.6.2

CSCtj90316

PMR 81134 CUCM Database assert failure after upgrade from 7.1(5)

CSCtq18720

Bulk Administration file/log migration of RU from 7.1.5 to 8.6.1

CSCtv21624

Upgrade from 7.1.5.10000-12 Restricted results in DRS unable to Restore

You can certantly do the upgrade direct to take some time, but I think  you should be aware of this caveats.

Raymond Choi
Level 1
Level 1

Thank you all for your great feedback! The sense of community and support in this forum is second to none.

Jonathan, thank you for the detailed implementation +5. Its very much appreciated and answered several questions/concerns I had.

Allan/Robert, thank you guys for providing additional information regarding the upgrade.I was unaware of the caveats listed for this upgrade path and have certainly taken it all in for consideration.

In addition to my concerns, I have a 48 hour maintenance window to perform the upgrade on the 6 servers which all reside on MCS7835-i3 hardware spread across the WAN. If I were to play it save and performed the two step upgrade to 8.5 and then to 8.6, would/could it be possible to perform it in the 48 hour timeframe as long as the DB replication is ok? Would this be increasing the risk or just pushing it too much?

Cheers

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: