[cisco-voip] CUCM6.1.4 Upgrade to 8.6.X on New Hardware

[Joe Martini]

Having 6.x on VMware is not supported, even if you don't license it.

Proposed:
1) Physical 6.x backup.
2) Install 6.x on VMware.
3) Restore the backup from the physical server in VMware.
4) Upgrade the VM to 8.x.  Due to steps 3 and 4, the resulting system/backup is technically unsupported.

Supported:
1) Upgrade the physical server to 8.x.
2) Take a backup of the physical 8.x server.
3) Install the same 8.x version on VMware.
4) Restore the production backup to the VM.


On Dec 5, 2012, at 7:47 AM, Alice Borgo <bertacco.alessandro at alice.it> wrote:

Hi Joe,
   License will be uploaded only on MCS server with Supported Hardware.
 
 
The VMware environment need me only to create a copy of Customer Cluster in version 6.1.4, enabling me to import the DisasterRecovery DB, and after that to migrate to final version 8.6.X
 
When in 8.6.X with DR i will export again DB.
 
Install on MCS supported hardware the same version 8.6.x, and import the DB
 
After all check, upload all license file.
 
What do you think about it?
 
Also understood the problem of the SUB, It will necessary upload all audio files and Firmware phone.
No problem with certificate because no security and no LDAP sync actually used.
 
 
Thank you for the reply.
 
Regards
 
Alessandro
 
Da: Joe Martini [mailto:joemar2 at cisco.com] 
Inviato: mercoledì 5 dicembre 2012 12:56
A: Abebe Amare
Cc: Alice Borgo; cisco voip
Oggetto: Re: [cisco-voip] CUCM6.1.4 Upgrade to 8.6.X on New Hardware
 
A few things to point out.  Installing or using any non 8.0.3 CUCM version on VMware is unsupported.  I've personally seen issues with the license manager service when putting a pre 8.0.3 CUCM version on VMware as you're looking to do, even after upgrading it to 8.x!  The supported method requires an upgrade on the current MCS server to an 8.0.3 or later version, backup, restore to a VM running the same exact version.  That's why we created bridged upgrades, so that you can install 8.x on hardware that doesn't support it, simply to take a backup to move to VMware.  
 
Adding to Abebe's reply, also remember that any custom TFTP files or MoH files will be lost using the rebuild method for the subscribers and letting them replicate.  Remember to put back MoH files on the subscribers and custom TFTP files, and even certificate loaded on the OS admin page for secure LDAP connections, etc.
 
Again, I'd highly recommend not using the 6.x on VMware method.
 
Joe
 
On Dec 5, 2012, at 6:40 AM, Abebe Amare <abucho at gmail.com> wrote:

you can install the subscriber directly on new hardware it will replicated the DB from the publisher.

regards,

Abebe
 

On Wed, Dec 5, 2012 at 2:26 PM, Alice Borgo <bertacco.alessandro at alice.it> wrote:
 
Hi guys,
   I need to Upgrade PUB + ONe SUB from 6.1.4 to 8.6.X on new MCS Hardware.
 
Customer want upgrade without modification on the actual Cluster, so I can't upgrade in place the cucm 6.1.4.
 
 
So using VMware infrastructure i made an exact copy of the 6.1.4 customer cluster.
 
Using Disaster Recovery export all PUB configuration from the Production Cluster and imported on the VMware copy.
 
Afeter that I'll proceed with the upgrade step 6.1.4 -> 7.1.5.33900-10 -> RefreshUpgrade -> 8.6.1.2000-1 on the Virtualized environment
 
After that Using again DisasterRecovery export DB of the virtualized PUB and the Import again in the MCS Hardware PUB.
 
Question for you!
 
Need to make the same for the SUB, or is possible to install the SUB directly on the MCS Hardware without all the upgrade step ?
 
Thank you very much
 
Regards
 
Alessandro Bertacco

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

 
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20121205/953d1b9a/attachment.html>