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 ?
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.
if this helps, please rate