Cisco Meeting Server(CMS) migration from one DC to another

Deploy/Upgrade 4 Minutes

CMS server is an On-prem conferencing component in the Cisco Collab portfolio. Came through the acquisition of Acano in 2015, CMS server has replaced the MCU/TPS servers and can be deployed in various options, CMS 1k, 2k, or spec-based.
You can check more details on the Cisco site about the product but just to give you a quick summary about use cases:

https://www.cisco.com/c/en_in/products/conferencing/meeting-server/index.html

  • Cisco – Microsoft/Avaya interop.
  • On-prem Conference resource
    • VC
    • WebRTC
  • Streaming/Recording integration.

There are a lot of deployment scenarios, but I will write a different post for that. Here is the Cisco live presentation which can provide you additional details about different components of CMS.

This is a little old but gives a good idea:
https://www.ciscolive.com/c/dam/r/ciscolive/apjc/docs/2017/pdf/BRKEVT-2665.pdf

Or, you can check the Deployment guide:
https://www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Deployment_Guide/Version-2-9/Cisco-Meeting-Server-2-9-Scalable-and-Resilient-Deployment.pdf

Keep the command/ mmp guide handy:
https://www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-9/Cisco-Meeting-Server-MMP-Command-Reference-2-9.pdf

Background

I’ve put together this checklist that gives you a quick overview of all the steps you need to do for Spec-based CMS server migration, which has Callbridge and DB config in the cluster. I will list existing resources available on the Internet and add a few things from my experience.
Before making any changes, please consult with Cisco TAC or do your own research /testing in the lab environment. In short, I am not responsible for any disaster 🙂

Software version – 2.9.x

IP / Subnet is usually tied to location/DC. So when you change DC, you may have to changes the IP address of the server too. Changing IP address VS hostname ( or both) has a different impact. If possible, try to change a few things at a time.
If you can keep the hostname/fqdn, it’s good ( less work in one change window, no change in certs, etc).

A support contract (Smartnet) isn’t tied to the serial number but with a contract number, in the case of virtualized software. So even if you have to rebuild it, support shouldn’t be an issue.

License is tied to MAC address of server NIC (in 2.x sw version). Since its a VM, just copy the MAC and when you build a new VM, manually set the same MAC address, so there wont be an issue with license 🙂

What are the options?

Backup and restore – Easiest 🙂
The only things not included in the backup are branding files and banners. You will need to copy that and transfer it.

Preparation


  • Installation should take less than 15 minutes. Please configure the same IP and System setting as an existing server for backup restore.
  • Refer to my earlier blog on how to access the server in new DC when configured with a different subnet. –> Cisco Expressway(VCS) migration from one DC to another (Important point)
  • Use WinSCP and copy the backup and branding/banner files to the new server.
  • Restore the backup on the new server using the command from CLI/mmp:
    backup rollback <name>
  • Now that you have restored the backup on the new server. Using console access through vcenter/vsphere, change the IP address of the interface a to new DC scheme:
    ipv4 a del <existing ip>
    ipv4 a add 10.1.2.3/16 10.1.1.1

    Note – a is the interface name.
  • On the new server, Disable the NIC until the change window or shut down the server until the downtime window.
  • Plan your change window and list all the dependencies. Example- DNS record updates with new IP, CUCM config changes (SIP trunk or media res-> conf bridge ), Callbridge cluster config (if the hostname is config, it’s ok).
  • Prepare your test plan.

In change window

  • Log on to your existing/old server. Make sure that Cluster DB is fine and this is not the Master in DB cluster. If it is the Master, maybe reboot once, so another server will become the master.
    database cluster status
  • Remove it from the DB cluster using the command (consult with TAC )
    database cluster remove
  • Once done, shut down the old server.
  • Update your DNS record as it may take few minutes to sync/reflect.
  • Start the new CMS server in the new DC.
  • Add the DB instance to the db cluster using the command:
    database cluster join <hostname/ IP address of any existing database in the cluster>
  • It will take few minutes (less than 5 minutes I guess. Depends on the size and BW) and the DB cluster should be in sync.
  • If any other call bridge is using DB of the old server, you should change that to use this DB now.
    database cluster connect <hostname/ IP address>
  • Fix your call bridge cluster if it’s configured using IP. Go to any other server/node using GUI, update the new IP for this server.
  • Reset your sip trunks to the CMS server and also verify the registration in the CUCM conference bridge (if you are using this cms server as a conf bridge for ad-hoc conf).
  • Do your usual testing. Especially distributed call if it’s configured with Callbridge cluster.

Conclusion

Migration of UC servers isn’t an easy task and you may see some different challenges based on your deployment, dependencies and process. So plan it good. Write things down. Communicate with all stakeholders. Have people on standby.

I hope this helps. If you have any feedback, suggestions, please feel free to put in the comment or DM me on LinkedIn. Thank you for your time.

Published by Lalit Pamnani

Published

Leave a comment