cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7972
Views
0
Helpful
6
Replies
Beginner

CUCM 6.1.4 up to 8.6 - MCS to VMWare

Hello,

we are looking to upgrade a customer from 6.1.4 to 8.6, and at the same time migrate them from their MCS7816-I3 onto the customer's existing IBM Blade Centre.  The current MCS7816 servers have only 2G RAM (and is now EOS so no supported RAM upgrade is available), which is part of the reason they want to change platforms.

For us to do the upgrade/migration, I think we need to to the upgrade on the MCS servers, and then restore them to the Virtual servers which would have 8.6 preloaded.  My question is can we do the upgrade to 8.6 on the 7816 with the limited RAM?

The customer has about 250 users across 7 sites and we are using the 3+3 migration kit.

Thanks

Everyone's tags (4)
1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Beginner

Re: CUCM 6.1.4 up to 8.6 - MCS to VMWare

Our migration went well, the customer also wanted to move their CM and Unity systems from site, into their data centre, which of course requred us to readdress the servers - this was done on the old version as it is much easier than 8+.  Here is a summary of what the tech did - I am not a hands-on guy so won't be able to elaborate much on this.

  1. Enable peer firmware sharing on all phones
  2. Upgrade IOS on all voice gateways (VG224s included)
  3. Install Device Pack on current system to get phone loads to a level (8.5.2 I believe) where they will take the code in CUCM 8.5
  4. Change IP address on one server. Also change in DNS. Shutdown. Move to DC. Bring back up. Ensure everything working. Check DB replication. If this server is the TFTP server, change option 150 on all DHCP scopes
  5. Reset all phones so they get new configuration file with changed server IP address. Confirm either on a sampling of phones or via web browser to phones
  6. Change config on all IOS voice gateways to include new server IP address
  7. Change IP address of CUCM on Unity. Restart Unity sevice. Confirm Unity connectivity to both CUCM servers
  8. Change IP address on second server. Also change in DNS. Shutdown. Move to DC. Bring back up. Ensure everything working. Check DB replication. If this is the TFTP server, change option 150 on all DHCP scopes
  9. Reset all phones so they get new configuration file with changed server IP address. Confirm either on a sampling of phones or via web browser to phones
  10. Change config on all IOS voice gateways to include new server IP address
  11. Change IP address of CUCM on Unity. Restart Unity sevice. Confirm Unity connectivity to both CUCM servers
  12. Upgrade to 8.5 on physical boxes. Allow phones to download 9.x firmware
  13. Upgrade TSP drivers on Unity for new version of TSP on CUCM
  14. Backup CUCM system
  15. Shut down publisher
  16. Install 8.5 in VMWare with exact same settings as the shutdown publisher including hostname, IP address, certificate information, admin password, shared secret, application username/password
  17. Restore publisher and by extension entire cluster from backup. Restart all servers
  18. Ensure functionality
  19. Shut down subscriber server
  20. Install 8.5 in VMWare with exact same settings as the shutdown subscriber including hostname, IP address, certificate information, admin password, shared secret, application username/password
  21. Restore subscriber from backup. Restart subscriber
  22. Upgrade to 8.6 on both. Complete CUCM outage for a couple of hours. Change VMWare guest operating system to RHEL 5.
  23. Testing

View solution in original post

6 REPLIES 6
Highlighted

Re: CUCM 6.1.4 up to 8.6 - MCS to VMWare

You can check compatibility for the server here:  http://www.cisco.com/en/US/prod/collateral/voicesw/ps6790/ps5748/ps378/prod_brochure0900aecd8062a4f9.html

It looks like the server is supported to 8.6, but would require more memory (as you stated).  You could just throw some third-party memory in there to perform the upgrade, then move it to VMWare.

Highlighted
Beginner

Re: CUCM 6.1.4 up to 8.6 - MCS to VMWare

As tdavidson mentioned you will need an upgrade to 4GB.

Here is the migration steps I will be taking over the next week for a client.

  1. Log TAC with Cisco in preperation for the upgrade.
  2. Remove SAS HDD drive and replace with Spare supplied by Cisco from the Publisher.

     

  1. Create new Virtual CUCM Publisher server (Week 1)


 

  1. Pre-check – Confirm IP Address and Hostname for new Location
  2. Deploy OVA
  3. Perform Installation using 8.6.1a media
  4. Upgrade using 8.6.2 patch
  5. Disable Network Port
  6. Add new hostname to DNS
  7. Configure services
  8. Add Locale 
  1. Build virtual subscribers (Week 1)

     

  1. Pre-check – Confirm IP Address and Hostname for new Location
  2. Deploy OVA
  3. Perform Installation using 8.6.1a media
  4. Upgrade using 8.6.2 patch
  5. Do not connect to Publisher ( Leave half installed)
  6. Disable Network Port
  7. Add new hostnames to DNS

PHASE 2 - BRIDGE MODE UPGRADE - Version 7.1.5.33900-10 to version 8.6.2.20000-2


Supported version: http://www.cisco.com/en/US/prod/collateral/voicesw/ps6790/ps5748/ps378/prod_brochure0900aecd8062a4f9.html

MCS - 7845H2

(5) Supported only for "bridged upgrade" to migrate to newer hardware. In a bridged upgrade, you upgrade to the specified Cisco Unified Communications Manager version, make a backup of your software configuration via the Disaster Recovery System utility, reinstall the Cisco Unified Communications Manager version on new hardware, and restore your software configuration from backup. This server is not supported for any other use with Cisco Unified Communications Manager other than this "bridged upgrade" procedure.

Apply Null Routes to all remote site core switches to CUCM servers IP address



Publisher Upgrade from Version 7.1.5.33900-10 to version 8.6.2.20000-2

Day Prior an HDD will be swapped out and kept in a secure place

  1. Review hardware requirements
  2. Open TAC case
  3. Backup DB - Local and Remote Set 
    • Local - Laptop SFTP
    • Remote - 10.80.8.112 - CUCM - AIDg6gtEI8JO
  4. Document the number of registered IP Phones from RTMT 
  5. Document the number of services that are down from RTMT 
  6. Apply Peer Firmware Sharing common profile setting to all IP phones and reset phones
  7. Restart all IP Phones to ensure DHCP update
  8. Copy upgrade file to Publisher using SFTP or FTP 
    • File Name: UCSInstall_UCOS_8.6.2.20000-2.sgn.iso
    • md5: 15c7b1ea0d8bfd5fd01987f26f43e8c5
  9. Check MD5
  10. Perform upgrade to Publisher
  11. Restart Publisher to Upgraded partition
  12. Perform a series of tests on new partition 
    • Inbound and outbound calls
    • Inter and Intra site dialing
    • Update a device and line to ensure cross cluster interop
    • Perform DB checks

  Subscriber 01  10.76.50.101 upgrade from Version 7.1.5.33900-10 to version 8.6.2.20000-2  

Day Prior an HDD will be swapped out and kept in a secure place

  1. Create and implement an ACL to block all subnets to 10.76.50.101
  2. Ensure Publisher has been upgraded and restarted before continuing
  3. Note the amount of IP phones registered on this server
  4. Disable CCM service
  5. Confirm all phones not in SRST now reside on Subscriber 2
  6. Copy upgrade file to Publisher using SFTP or FTP
  7. Check MD5
  8. Perform upgrade to Subscriber
  9. Restart Subscriber 01 to Upgraded partition
  10. Note the amount of IP phones registered on this server and ensure that they
  11. Perform a series of tests

  Subscriber 02 10.75.42.10 upgrade from Version 7.1.5.33900-10 to version 8.6.2.20000-2  

Day Prior an HDD will be swapped out and kept in a secure place

  1. Create and implement an ACL to block all subnets to 10.76.50.101
  2. Ensure Subscriber 01 has been upgraded and restarted before continuing
  3. Copy upgrade file to Publisher using SFTP or FTP
  4. Check MD5
  5. Perform upgrade to Subscriber
  6. Restart Subscriber 02 to Upgraded partition after subscriber 01 has been restarted
  7. Perform a series of tests

Upgrade TSP on third party API's

  1. Download TAPI from CUCM
  2. Install on Voice Recording Server
  3. restart server
  4. Install on ARC server
  5. restart server
  6. Perform voice recording tests

PHASE 3 - MIGRATE PUBLISHER FROM PHYSICAL TO VIRTUAL PLATFORM

Platform Conversion -MCS to Virtual Machine

     

  1. Swap SAS drive 1 day prior
  2. Backup CCM DB using DRS
  3. Note Services in RTMT
  4. Note IP Phones registered across the cluster
  5. Disconnect MCS Publisher from Network by shutting down the access port on the switch
  6. Test Connectivity is unreachable
  7. Connect the Virtual adapter on the virtual Publisher to Virtual Switch
  8. Test Connectivity (server is reachable)
  9. Restart Server
  10. Restore CCM DB for Publisher on virtual server using DRS
  11. Restart Server
  12. Confirm Replication across cluster is 2
  13. Show tech network hosts to confirm cluster configuration information
  14. Note Services in RTMT compared to note 2
  15. Note IP Phones registered across the cluster compared to note 3
  16. Test TSP connection using ARC
  17. Test CTI - Veriant call recording
  18. Test SCCP - CUC voicemail
  19. Test SIP - Kirk Connectivity



Add additional Subscribers to virtual environment (Week 4)

 

 

  1. Add Subscriber entries into CUCM Publisher
  2. Continue installation on Subscribers
  3. Check DB replication
  4. Configure Services
  5. Install Locales to all servers

     

  1. Migration of all Call Processing to new Subscribers (Week 5)
  1. Update CCM Groups with new  virtual Subscriber servers and reset Devices
  2. Update DHCP Scope option 150 with both the virtual subscribers.
  3. Ensure all IP Phones register with new subscribers by comparing documentation.
  4. Update all Cisco Unity Connection SCCP Port configuration
  5. Update ARC Addressing for CTI
  6. Update Veriant server SIP trunk
  7. Update all MGCP gateways with IP addressing for new virtual Subscribers
  8. Update all Kirk SIP gateways with IP addressing for new virtual Subscribers
  9. Ensure the overseas Intercluster trunks and H323 devices have been updated to reflect the new Subscriber Addressing.
  10. Backup CUC, CUCM, ARC, Veriant, MGCP and IOS config.
  11. Update Network Monitoring tools
  12. Update AS BUILT and Handover to IBM Support

     

  1. Decommission

  Submit CR - NOT COMPLETED 19/12/2011

  1. Monitor both subscribers for any calls on old Subscribers
  2. Shutdown old Subscriber 01
  3. Shutdown old Subscriber 02
  4. Remove MCS servers from racks after 1 month

Highlighted
Beginner

Re: CUCM 6.1.4 up to 8.6 - MCS to VMWare

had u face any thing when restore on Virtual machines from MCS, its was ok ?

kindly share experience

also if i have to make MCS as additional subscriber, raplication will be ok or no .... Kindly share and nice plan to move on

Highlighted
Beginner

Re: CUCM 6.1.4 up to 8.6 - MCS to VMWare

Our migration went well, the customer also wanted to move their CM and Unity systems from site, into their data centre, which of course requred us to readdress the servers - this was done on the old version as it is much easier than 8+.  Here is a summary of what the tech did - I am not a hands-on guy so won't be able to elaborate much on this.

  1. Enable peer firmware sharing on all phones
  2. Upgrade IOS on all voice gateways (VG224s included)
  3. Install Device Pack on current system to get phone loads to a level (8.5.2 I believe) where they will take the code in CUCM 8.5
  4. Change IP address on one server. Also change in DNS. Shutdown. Move to DC. Bring back up. Ensure everything working. Check DB replication. If this server is the TFTP server, change option 150 on all DHCP scopes
  5. Reset all phones so they get new configuration file with changed server IP address. Confirm either on a sampling of phones or via web browser to phones
  6. Change config on all IOS voice gateways to include new server IP address
  7. Change IP address of CUCM on Unity. Restart Unity sevice. Confirm Unity connectivity to both CUCM servers
  8. Change IP address on second server. Also change in DNS. Shutdown. Move to DC. Bring back up. Ensure everything working. Check DB replication. If this is the TFTP server, change option 150 on all DHCP scopes
  9. Reset all phones so they get new configuration file with changed server IP address. Confirm either on a sampling of phones or via web browser to phones
  10. Change config on all IOS voice gateways to include new server IP address
  11. Change IP address of CUCM on Unity. Restart Unity sevice. Confirm Unity connectivity to both CUCM servers
  12. Upgrade to 8.5 on physical boxes. Allow phones to download 9.x firmware
  13. Upgrade TSP drivers on Unity for new version of TSP on CUCM
  14. Backup CUCM system
  15. Shut down publisher
  16. Install 8.5 in VMWare with exact same settings as the shutdown publisher including hostname, IP address, certificate information, admin password, shared secret, application username/password
  17. Restore publisher and by extension entire cluster from backup. Restart all servers
  18. Ensure functionality
  19. Shut down subscriber server
  20. Install 8.5 in VMWare with exact same settings as the shutdown subscriber including hostname, IP address, certificate information, admin password, shared secret, application username/password
  21. Restore subscriber from backup. Restart subscriber
  22. Upgrade to 8.6 on both. Complete CUCM outage for a couple of hours. Change VMWare guest operating system to RHEL 5.
  23. Testing

View solution in original post

Highlighted
Beginner

Re: CUCM 6.1.4 up to 8.6 - MCS to VMWare

why u changed the ip of existing servers (MCS) ....

Highlighted
Beginner

Re: CUCM 6.1.4 up to 8.6 - MCS to VMWare

since the servers were going to be relocated to another site, they needed to be readdressed to something in the new site's subnet.  the changes were made to the MCS servers on Rls 6, since making the changes on Rls 8 is more difficult.

CreatePlease to create content