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.
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?
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.
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.
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.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
[toc:faq]CUCM Database Replication is an area in which Cisco customers
and partners have asked for more in-depth training in being able to
properly assess a replication problem and potentially resolve an issue
without involving TAC. This document discusse...