TMS /TMS-XE Migration Advice

[rchaseling]

Hi All,

Looking for advice. Customer has TMS with Backend SQL & TMS-XE all on W2012 / SQL 2014  and we have to migrate everything to fresh builds of W2019 / SQL2019 (no in place OS upgrade)

Their preference will definitely be to build it side by side and test it extensively before "cutting across" but i assume this will not be a runner as there would be conflicts.

Is the best option to have all the servers build/SQL installed etc and then request a maintenance window. Take a backup of the SQL2012 database, Power down the legacy servers, change the IPs of the 2019 server to the same as the legacy and then import SQL database to 2019 (assume this is possible) and then install TMS/TMS-XE followed by testing

This i assume would give a clean rollback if required - in just powering back old servers but there is no advance testing

TO note we'd be deploying latest version of TMS too on new builds if that makes things any different.

Has anyone any experience in doing this sort of migration and would have any tips or gotchas?

TIA

Russell

[rchaseling]

Bump

[Wayne DeNardi]

There's a well documented (it's a little dated, but the steps are still the same) procedure for the SQL migration - see TMS SQL Database Migration from one SQL Server to another SQL server.

Step 4 has the important steps about pointing TMS to the new SQL server (whether this be the existing one, or a newly set up one).

The new SQL Server does not usually need to have the same IP address as the old one, but keeping the TMS server on the same address can often be helpful.

[rchaseling]

Hi Wayne - Sorry for late replay....I'm just back from leave.

Thanks very much for the doc - that will definitely be helpful but to drill down a bit. After having further discussions with the customer, their preference by a long way is to build TMS, TMS-XE and TMS SQL with new W2019 OS with new DNS names and new IPs and leave them that way - the next preference down would be an in place OS upgrade.

Taking their first preference ... I would install the above apps as a fresh build get them all connected and then in a maintenance window export the database from the old SQL to the new? Or would there be issues because the new TMS has already setup/configured the new SQL database? Probably need a SQL Admin to do a purge before the import......

My only concerns with this would be the implications of having the new and old systems online at the same time and the testing - I assume the only way to test the new system in advance would be to add a test VC Unit to the new TMS and make sure it works and then once happy purge the SQL DB in a window and import the old ....... see any isues doing it this way?

Thanks

[JJ77]

Here's my recommendation :

Take a screenshot of existing TMS server configuration (old school way of taking it on word is better)

1)Build a new SQL server on new W2019

2)Replicate old db onto the new SQL server 

3)Install TMS on new W2019 

4)During configurations stage of the new TMS, point the DB to the new SQL server 

5)Install TMSXE on new W2019 and point it towards the new TMS

6)Update DNS entries as needed  

You should power off the old tms between step 3 and 4 to avoid conflict 

You should power off the old tms between step 4 and 5 to avoid conflict 

Cross the check the configuration of the new TMS server with the screenshot taken of the old TMS server 

Its obvious but important to mention, do not add,remove ot change any configuration during the transition from old to new 

Also, have a local account login setup on both old and new TMS just incase SSO breaks down (hope so not )

Hope this helps ..

Please remember to rate responses and to mark your question as answered if appropriate.

[rchaseling]

Thanks for the great advice - the issue i have is that the customer requires a period of testing which means I cannot do it all in one window and the new servers will need to have new IPs and DNS names.

Does anyone know whether TMS-XE is constantly polling the Enpoints mailboxes for meetings or does it only do it the once when the meeting is scheduled? In other words will a new deployment of TMS-XE/TMS populate all historical meetings ? Or is the only option to import the TMS DB during a window otherwise I'll lose all historical meetings?

[JJ77]

Hi,

The polling between TMS and TMSXE is done every minute.There are services running on TMS and TMSXE which can be stopped and thus the polling along with other dependant services will not replicate or sync between TMS and XE.

Here's the link (refer to step 1- https://www.cisco.com/c/en/us/support/docs/conferencing/telepresence-management-suite-tms/212319-tms-sql-database-migration-from-one-sql.html)

Extract from the above mentioned document as follows:

Step 1. Stop the TMS Application Services, including IIS and WWW 

In order to locate and stop the services, access the TMS server via console or RDP connection, and run the command services.msc in the Command Propmpt. Within the list of services, locate the ones below and right click on each of them, in order to stop it:

• TMSDatabaseScannerService
• TMSLiveService
• TMSPLCMDirectoryService
• TMSSchedulerService
• TMSServerDiagnosticsService
• TMSSnmpService
• World Wide Web Publishing Service (W3SVC)
• IISADMIN (optional)

The new deployment of TMS-XE/TMS should be able to get historical meeting as along as you are restoring using the DB from latest backup and thats precisely the reason I mentioned in my earlier post that no changes should be made during the transition

Thanks

Please remember to rate responses and to mark your question as answered if appropriate.

[terry.desjarlais]

We are in the process of migrating our TMS and other infrastructure to a new datacenter and wanted to ensure that everything was well tested. We run everything on VMWare so we just backed up the VM and installed it in the new datacenter. When it came up I renamed it and deleted and purged all of the systems from it. From there I just started adding systems to test.

There is obviously more to it than that, for instance we are also moving our VCS pair so those config items in TMS needed to be changed.