CUCM 6.1.4 up to 8.6 - MCS to VMWare

[doug-curror]

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

[TIMOTHY DAVIDSON]

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.

[Matt McAuley]

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

[alap84]

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

[doug-curror · Accepted solution]

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

[alap84]

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

[doug-curror]

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.