TMS server migration

[since1976]

If I were to change the hostname and the ip address of the TMS server.

And I use a configuration template to move all endpoint management host to the new ip address? Will this work?

Also can I run 2 copies of TMS concurrently until I have my migration done? For a period say 2 weeks?

[Simon Battye]

Hi,

I don't see why this would not work, if you pushed out a configuration template to change the traphost/management address.

I've done a similar migration before; and run two instances of TMS parallel, but this was for redundancy/resiliancy purposes, running from the same DB.

Are you building the TMS instance from the existing SQL DB? Or is this completely new?

Thanks, Si

[since1976]

Hi Simon,

This is an existing set-up which I am going to move to new vm servers.

[mayank.sharma]

I was wondering if coverting TMS running on Physical box to VM is supported using VM Converter would work.

That would be much easier I would think as then you would not need 2 instances of TMS running unless you specificly want to take this opportunity to change the hostname and IP address of the TMS Server. 

[Magnus Ohm]

Hi, you dont need configuration template to do this. Fill in the traphost ip + ipv4 address and the new fqdn under network settings in tms and press enforce now on the enforce management settings option. This will update the traphost, management address and the feedback address on all the systems.

It depends if you are running the tms servers in the same network and does it mean you have two copies of the database running as well or are both tms servers pointing at the same external db?

If both are pointing at the same db and both is running with all services up it can cause potential problems with bookings and unessecary load on the network. Why do you want to do this? Is it to get a smooth migration from one fqdn to another?

Sent from Cisco Technical Support iPhone App

[scoglass]

To add to what Magnus stating, there are other considerations.  If you have a VCS in play and are using any SIP or provisioning services that would require TMS to have TMS Agents or the replication agents turned on, as well as any VCS clustering that are either physical or vitrual, you must deactivate those Agents and they cannot co-exist with two instances of TMS.

[since1976]

Thanks on that note.

I was thinking about it as well, suppose I have 2 instances of the TMS running side by side. And because TMS agent or replication agents runs everyday, my worry is that how does VCS know which one it should synch up with?

And you are right, it did slip my mind that we can stop TMS agent in TMS side (the new server) till migration is over.

[since1976]

Yes, I want to cut short the migration time.

Previously we have some fire fighting and we have to rebuild OpenDS on both the VCS and the TMS side. It was a pain especially we have 2 individual VCS and 1 cluster VCS to rebuild.

[Magnus Ohm]

Hi

I'm not 100% sure what the ultimate goal is here and what you are planning to migrate. I assume its just a server migration correct? But while you are doing this migration would it also not be a good time to upgrade the TMS and start implementing the TMS Provisioning Extension which replaces OpenDS. The sooner you migrate to the new provisioning extension the better as OpenDS will be excluded in one of the next major releases which means in order to upgrade you have to migrate to the new provisioning extension anyway.

But there are benefits here since you wont have to deal with the opends replication setup anymore.

/Magnus