CUCM 7.1.5SU4 upgrade to CUCM 8.6.2aSU2

[ahoang9996]

Hi All, I have the following CCM cluster

1 x Publisher

6 x Subscribers

2 x Tftp servers

All nodes are running on MCS-7845H2.  The Publisher had HDD upgraded to 146GB, the rest of the nodes still have the original 72GB HDD.  All servers have 4GB RAM.  My plan is to upgrade to CUCM 8.6.2aSU2 and at the same time convert the hardware to UCS 210M2.  I have verified the supported upgrade path, compatibility matrix, supported hardware, etc, but I want to skip a number of steps (ie upgrading all the existing servers, backing up, only then to convert them to UCS and restore them again).  I'm considering the following upgrade method:

1. Upload CCM 8.x software feature license ahead of time
2. Upgrade the Publisher to 8.6.2aSU2 on the MCS-7845H2
3. Once pub is running 8.6.2aSU2, shutdown the 7.1.5SU4 TFTP servers on MCS-7845H2
4. Spin up the 8.6.2aSU2 replacement servers on UCS with OVA template for TRC1 (using same hostname, ip addr, password, etc).  This will be like replacing a subscriber or adding a new subscriber to an existing cluster.
5. Upload all the necessary custom logo, phone firmware, etc, start the tfp service
6. Once TFTP servers are ready, shutdown call processing nodes (one by one of course) on MCS-7845H2
7. Spin up the 8.6.2aSU2 replacement servers on UCS (same OVA template for TRC1).  Again using the same hostname, ipaddr, password of the server it is replacing.  Because the original server is already shutdown, there is no ip conflict
8. Once all nodes are replaced with 8.6.2aSU2 running on UCS 210M2 hardware, verify DB replication is good (all 2) and phones are registered, backup the entire 8.6.2aSU2 cluster using DRS
9. At this point, the cluster has the following:
   • 1 Pub on MCS-7845H2
   • 8 subscribers on UCS 210M2
   • All nodes are running the same CCM version
10. Verified back up is 100% completed, power down the Pub on MCS.
11. Spin up the replacement servers on UCS (again same hostname, ipaddr, pw, etc)
12. Restore the DB from previous backup (only restore the Pub node).  Same as restoring a Publisher procedure
13. Rehost the license before the 30 days grace period
14. At this point, all servers are running on UCS hardware with 8.6.2aSU2 version

I have tested this procedure in the lab with a smaller cluster duplicating as much of the production environment as possible.  Everything seems to be working.  However, I'm concern that the lab don't represent the true production cluster and I may have missed something.  Also this is not a secure cluster, so I don't think certificate will be an issue.

Will work or will I have problems?  I appreciate any comments or input.

Thanks,

Andy.

[chrysostomos1980]

Hi ahoang9996

just to clarify

You will shutdown ALL the SUB servers.

Upgarde the  PUB CUCM to 8.6.2aSU2.

Create  a vm machines into UCSS using OVA file..

Installed All the SUB CUCM servers with the same configs as the mcs servers (ips, hostnames , etc) running

8.6.2aSU2 version

Then switch on ALL the SUB cucms into UCSS server

At that time the PUB will replicate the database to the whole SUB servers

Backup ALL the cluster(be carefull with that.you have to receive a success backup for all the machines)

Switch off the PUB.

Then create a vm into UCSS for the PUB with the same configs as the mcs PUB

Restore only the PUB from the DRS

if i understood correct your scenario is excellent.....

Note:

Be sure that the PUB can handle ALL the phones when it will be ALONE if is not a maintance time,But may it will be a maintance time

Regards

chrysostomos

[ahoang9996]

Any reason why I need to shutdown all the SUBs?  I believe if there is a version mismatch, DB replication will not work anyway.  Although this will be done during maintenance window, there are about 15K phones registered and I want to minimize service impact as much as possible.  This is how I plan to minimize impact:

1. Upgrade PUB.  No phone reset (no change can be made to the system).  Ensure device defaults use the same phone firmware as before the upgrade (avoid phone firmware upgrade)
2. Upgrade TFTP servers. No phone reset.  New TFTP servers will sync with new PUB
3. Upgrade secondary Subscribers. No phone reset.  New subscribers will sync with new PUB
4. Upgrade primary Subscribers.  Phone re-register to new secondary Subscribers (no firmware upgrade).  New subscribers will sync with the new PUB
5. Cluster should now be synced (verify on PUB with command "utils dbrep runtimestate")

Although, I've enabled PFS (peer-firmware-sharing), I still want to avoid upgrading phone fw en-masse because it could have huge impact on our WAN.

Thanks for your input.

Andy.