Cisco Meeting Server (CMS) Migration from One DC to Another¶

Published: April 17, 2021
Read time: 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:

Cisco Meeting Server Product Page

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 a Cisco Live presentation which can provide you additional details about different components of CMS.

This is a little old but gives a good idea:

BRKEVT-2665 CMS Presentation

Or, you can check the Deployment guide:

CMS 2.9 Scalable and Resilient Deployment Guide

Keep the command/MMP guide handy:

CMS MMP Command Reference

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.

Disclaimer

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 change the IP address of the server too. Changing IP address vs. hostname (or both) has a different impact. If possible, try to change fewer 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 to 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 the MAC address of the server NIC (in 2.x software version). Since it's a VM, just copy the MAC, and when you build a new VM, manually set the same MAC address—so there won't be any issue with the 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 those and transfer them separately.

Preparation¶

Take a backup of the existing server using the command from CLI/MMP:
```
backup snapshot <name>
```
Use WinSCP and copy the backup file and any banner/branding files.
Deploy new VM using OVA in the destination (new) DC. Choose the correct file for your ESXi version: CMS 2.9.3 Download
Installation should take less than 15 minutes. Please configure the same IP and System settings as the existing server for backup restore.

Network Access

Refer to my earlier blog on how to access the server in the new DC when configured with a different subnet: Cisco Expressway (VCS) Migration from One DC to Another (Important point section)

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 interface a to the new DC scheme:
```
ipv4 a del <existing ip>
ipv4 a add 10.1.2.3/16 10.1.1.1
```

Interface Name

a is the interface name in the commands above.

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 resource → conference bridge), Callbridge cluster config (if the hostname is configured, it's ok).
Prepare your test plan.

In Change Window¶

Log on to your existing/old server. Make sure that the Cluster DB is fine and this is not the Master in the 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 a 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 a few minutes (less than 5 minutes I guess, depends on the size and bandwidth) and the DB cluster should be in sync.
If any other Callbridge is using DB of the old server, you should change that to use this DB now:
```
database cluster connect <hostname/IP address>
```
Fix your Callbridge cluster if it's configured using IP. Go to any other server/node using GUI and 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 conferences).
Do your usual testing. Especially distributed calls if 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 well. Write things down. Communicate with all stakeholders. Have people on standby.

Share Your Feedback

If you have any feedback or suggestions, please reach out via my Notion form or DM me on LinkedIn. Thank you for your time!