ucm 5.1.3 to 6.1.2 upgrade

Answered Question
Aug 19th, 2008

i have a cluster of 2 servers running 5.1.3 and have purchased CUWL upgrade for the cluster so i can use 6.1.2 and implement some new features. What is the best process for upgrading and getting the new licences through on the CUWL front. Also during the upgrade process can i leave all phones working on the sub, upgrade the pub reboot and then force the phones to reg with the pub. Does the sub automatically turn of services when you start the upgrade or should i manually shut down the services on the subscriber ?

I have this problem too.
0 votes
Correct Answer by Jaime Valencia about 8 years 3 months ago

that's why you need to install the upgrade on both servers and then reboot them in order. the version mismatch should not be any more than 5 minutes while you do the cluster reboot.

i'm not recommending it, that's the way the process is done and if you reboot one server after installing the upgrade without doing it on the other servers, the whole process will fail

i believe the process is really clear on the links:

Upgrading from Unified CM 5.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 Cisco Unified CM 5.x to Unified CM 6.x, any changes made to the subscriber's database in the active partition after the start of the upgrade process will not be migrated to the new version of the database.

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.

The 2:1 redundancy scheme allows for fewer servers in a cluster, but it can potentially result in an outage during upgrades.

Note You must use 1:1 redundancy when more than 7,500 IP phones are registered on the two primary subscribers because there cannot be more than 7,500 backup registrations on a single backup subscriber.

Note Before you do an upgrade, Cisco recommends that you back up the Unified CM and Call Detail Record (CDR) database to an external network directory using the Disaster Recovery Framework. This practice will prevent any loss of data if the upgrade fails.

HTH

java

if this helps, please rate

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Jaime Valencia Tue, 08/19/2008 - 13:18

first just confirm the compatibility for the upgrade:

Table 4 Supported Cisco Unified Communications Manager Upgrades for Release 5.x and Release 6.x

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/compat/ccmcompmatr.html#wp1268956

after the upgrade to 6.1(2) you will need to delete the old license file and upload the new CUWL license file to the server.

you need to install the upgrade on both servers and then reboot pub, wait until it fully comes up and then reboot sub.

services are not stopped when doing the upgrade, if you want to, you would need to stop them manually

HTH

java

if this helps, please rate

littledavewhite Wed, 08/20/2008 - 01:07

thanks for the update, do i delete the licence files through the command line ?

So i dont have to worry about the sub running an older version when the pub has been upgraded and the two server try to talk. I can just push on with upgrading the sub and let the database sort itself out when both servers are on the same code level. The guides are not very clear on the actual process. i see you recomend upgrading both servers and not rebooting after upgrade, untill all server ready to go on new code. then reboot cluster, pub first. is this correct.

Correct Answer
Jaime Valencia Wed, 08/20/2008 - 06:09

that's why you need to install the upgrade on both servers and then reboot them in order. the version mismatch should not be any more than 5 minutes while you do the cluster reboot.

i'm not recommending it, that's the way the process is done and if you reboot one server after installing the upgrade without doing it on the other servers, the whole process will fail

i believe the process is really clear on the links:

Upgrading from Unified CM 5.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 Cisco Unified CM 5.x to Unified CM 6.x, any changes made to the subscriber's database in the active partition after the start of the upgrade process will not be migrated to the new version of the database.

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.

The 2:1 redundancy scheme allows for fewer servers in a cluster, but it can potentially result in an outage during upgrades.

Note You must use 1:1 redundancy when more than 7,500 IP phones are registered on the two primary subscribers because there cannot be more than 7,500 backup registrations on a single backup subscriber.

Note Before you do an upgrade, Cisco recommends that you back up the Unified CM and Call Detail Record (CDR) database to an external network directory using the Disaster Recovery Framework. This practice will prevent any loss of data if the upgrade fails.

HTH

java

if this helps, please rate

littledavewhite Wed, 08/20/2008 - 06:36

Hi Java

excellent input, can you send me the link for the document. i have been looking for something like this.

Actions

This Discussion