cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

Operational Guide for Cisco Unified Communications Manager.pdf

19085
Views
1
Helpful
17
Comments

As customers plan to upgrade their Cisco Unified Communications Manager to take advantage of new features, and if the upgrade includes moving to virtual machines, the procedural steps to accomplish these tasks are not clear.   Cisco does provides documentation on how to upgrade, how to migrate to a virtual machine and what versions/servers are supported, but there is no one document that combines these 3 key areas into a single document that details the 'best practices' for planning an upgrade and migration. 

The Operational Guide for Cisco Communcations Manager is the one document that details the best practices for upgrading and migrating to Cisco Unified Communications Manager v9.x.  The document details upgrade from 6.x/7.x/8.x installs on physical MCS servers to 9.x servers running in a virtual machine. 

Comments
Enthusiast

Hello Dan.

I have a question regarding the migration process you have outlined in this document.

Page 10 - Number 6 and Page 11 - number 8.

I am questioning the need to shut down the entire cluster in order to build the new cluster. I understand that you need to use the same IP/Hostname when building the new cluster on UCS. However if we are forced to shut down the entire cluster we are looking at several hours with no phones.

In my past migrations of 7x (on MCS) to 8x (on UCS) I have done an in-place upgrade to 8x, DRS backup, shut down the Pub, fresh install of Pub on UCS, DRS restore of Pub, then shut down Sub(s) one at a time and fresh install on UCS. Would this same type of process not work when migrating to 9x on UCS? Are you saying that the only supported way of migrating to 9x on UCS is to shut down the entire cluster before building new cluster on UCS?

I look forward to your response.

Regards --

Jason

Cisco Employee

Jason,

Completely valid question. Myself and the other authors discussed this point at length before making the recommendation.  In the end we decided that the quickest way to restore a cluster was just that...restore the entire cluster at one time.  Doing it your way will require multiple cluster reboots as the individual servers are resinstalled, but by doing all the servers as new (which can be done concurrently too), then restoring the cluster will be a single step.  For a briged mode, it's no brainer because the cluster is already down, but for a cluster that can support 9.0, this path will be quicker than trying to do one server at a time.  Additionally, as mentioned in the ground rules section of the doc, you must use DRS backup and restore.  A new installation of CUCM will not have vital information neeed to run the desired services. 

If you are comfortable with using the single server replacement method to replace hardware, then once on 9.0, you can use that method to replace each node in the cluster.  Trade off is phone uptime vs length to complete the upgrade and restore the data.

Thanks,

Dan Keller

Technical Marketing Engineer

Enthusiast

Dan.

Thanks for your response. Follow up question. If minimal phone downtime is my goal (think 24x7 healthcare facility) then would it make more sense to do an in-place upgrade to 8.5 and then migrate to UCS (process outlined in my first comment). Then do an in-place (refresh) upgrade to 9.1.

Thanks.

--Jason

Cisco Employee

Jason,

Yes, the path you have descirbed will work just fine.  But when discussing upgrades, there may be different requirements during the upgrade process.  If there is a requirement for minimal down time, then an intermediate upgrade and server migration/replacement will accomplish that.  If there is a requirement to get to the target version w/ minimal installs, then this document covers that.  Many customers have a validation process for a specific version and they don't want to qualify and install an intermediate version, so efficiently upgrading to the target version is the requirements.

This document was written with the requirement for efficient upgrade in mind.

But I specifically added the section on single server replacement to include the high availability scenario you are talking about.  If that intermediate version that can be virtualized is 8.0(3) or 8.5(1) or 8.6(3), then it's the same process.  Hope that helps.

Thanks,

Dan Keller

Technical Marketing Engineer

Enthusiast

Awesome guide, many thanks.

I do have a couple of questions though in regards to the migration of licenses:

When the migration of licenses occurs within ELM, does it identify DLU's and/or registered end-points?

If DLU's, what about un-used DLU's, how does it determine what these will become (e.g. Enhanced, etc.)?

If not DLU's but rather end-points, does this mean that we will need to have all devices registered with CUCM prior to the migration (including the spare phones sitting in a cabinet....similar to what we had to do when migrating from v4)?

I look forward to a clear explanation as to the process as so far I have not found anything that makes sense.

Steven

VIP Advisor

ELM looks at the current database and looks at the endpoints registered to CUCM. Assuming the owner User ID field is set on the device it looks to see if multiple devices are assigned to the same owner User ID field. If they are and it is two, it is ENHP. If it is 3 or more but less than 10 it is CUWL STD

If it isn’t assigned it looks at the model of the phone. As an example 7900/8900/9900 will be ENH, 3905 is essential and 6911/21 will be basic

If there are more SNR profiles than phones then it will be basic. EM profiles don’t take any licensing

Whatever DLU is left over now can be allocated to increase your user count. Keep in mind that let’s say you are a UCL customer you should not use the left over DLU to increase your CUWL count because you never paid for a CUWL migration license. on the other hand if you are a current CUWL customer you can increase your CUWL count. Keep in mind licensing will cut you the key based on what they see from ELM.

Any PAK has to be registered to the system prior to running the migration. If the phone isn’t registered then it will see them as unused DLU. But don’t leave PAK unregistered since after you migrate you cannot go back to reclaim them

Thanks

Srini

What is the public link for this upgrade guide?  thanks

Cisco Employee

Yes, this document is available on CCO.

Cisco Unified Communications Manager 9.1 Migration and Upgrade Guide

Thanks,

Dan Keller

Technical Marketing Engineer

Community Member

Hi Dan.

I'm planning an upgrade from 6.1(5) to 9.1.1.

I think to go with "Direct-to-Release 9.x upgrade path". Just one question. "Install refresh upgrade Cisco Options Package (COP) file", is it an optional phase or mandatory?

Regards,

Community Member

Hi Dan.

I'm planning an upgrade from 6.1.5 to 9.1. I'm thinking to go with "Direct-to-Release 9.x upgrade path".

Just one question. About "Install refresh upgrade Cisco Options Package (COP) file", it It an optiona phase or mandatory?

I don't understand this.

Bye.

Cisco Employee

The Refresh Upgrade COP file is a required install for all nodes in the cluster before upgrading to CUCM 9.1.

Thanks,

Dan Keller

Technical Marketing Engineer

Community Member

Thank you very much Dan.

Regards,

Community Member

Hi Dan, again me :-)

The upgrade of my previus question has gone very well, thank you very much for your suppor.

Now I'm working with another customer where there is a cluster with two 7825H4. In the document yow make some Consideration for Refresh Upgrades on 7825H3 and 7828H3 servers. Is this consideration exclusively for 7825H3 or for subsequent version too? The mean, is the consideration valid for 7825H4 too?

Thank you very much.

Regards,

Cisco Employee

Antonio,

The recommendation for those two servers specifically.  The 7825H3 and 7828H3 servers have software RAIDs.  So when doing a Refresh Upgrade, the SW RAID would have been upgraded and all the data wiped out. To minimize the risk of the RU upgrade on this platform, we recommend to upgrade to 8.0(3) (an L2 upgrade), then replace the MCS servers with VM, then upgrade to 9.x.  The upgrade is now a high available and failback is much easier.  7825H4 is a different server and the recomenation it do a direct to 9.0 upgrade. 

Thanks,

Dan Keller

Technical Marketing Engineer

Community Member

Thank you very much Daniel.

Regards,

CreatePlease to create content
Content for Community-Ad
August's Community Spotlight Awards