We got to know Transporter can migrate jobs from one instance to another.
We installed Transporter 6.1 and successfully connected to 6.1 instance, but how to connect to 5.3?
What is the connection details should we give in the Transporter? Cant see any HTTP in 5.3
Transporter CANNOT transport using mismatched versions. The source and destination versions must be the same version as the Transporter version.
If you are using 6.1 Transporter, you can only transport to and from TES 6.1 environments. If using 5.3.1 Transporter, you can only transport to and from TES 5.3.1 environments.
The upgrade itself will upgrade them all from 5.3.1 to 6.1 so there is no other tool to migrate jobs from 5.3.1 to 6.1.
You can have the TES 6.1 application server on a new server. You will just need to point to the 5.3.1 database to upgrade it from 5.3.1 to 6.1. using the latest 6.1 upd.xml.
Problem is we not using same servers to install/upgrade Tidal.
We using whole new 3 Linux servers (Database, Master & Client manager) for 6.1.
At the moment 5.3.1 is and 6.1 is up and running in different enviroments (servers).
Can we copy Tidal database schema from 5.3.1 into 6.1 database and re-install 6.1?
Would that upgrade exsisting Jobs?
The best way to do it is to install the master as you already have, make sure that the latest upd.xml from your hotfix is in master/config/ , then edit the master/config/master.props file to point to the new database that you have copied from your 5.3.1 installation.
Before starting the master pointed to the new copy of your 5.3.1 database, run this command on the new copy of the database. It will set your system queue to zero so that no jobs run. If your 5.3.1 and 6.1 environments are running the same jobs at the same time are both active, you're going to run into issues.
UPDATE quemst SET quemst_limit = 0 WHERE (quemst_id = 1);
Next, start up the master and watch master/logs/scheduler.out as the database is upgraded.
Was going to add that once you start the master (if there is something in the schedule) the events will continue to fire even if queue is set to zero . Like timeouts events etc. I guess pausing scheduler may disable firing of events - but you cannot test a few jobs with scheduler paused.
Also keep in mind the deluge of jobs that will fire as soon as you release the system queue. So maybe best to also create a admin only queue that you can release while leaving the other queues dammed up, so that you can atleast sanity test on a controlled basis prior to releasing all queues and all hell breaks loose We don't have a lot of granularity in our queue so I had to do this, you may already have good queue controls in place.
> the events will continue to fire even if queue is set to zero
I did not think of that. Very good to know. I'm wondering if there's a safe way to disable all events.
Yeah, learned that the hard way when I was practicing on a copy of PRD, all my agents, jobs were disabled and queue = 0 but emails started getting sent that looked like it came from our real PRD. For my final practice pass I will delete all existing schedules as well (obviously not for the real go live...maybe...)
We had tried your method.
But hitting some issue with login in CM.
It dose not allow to login after upgrade.
Is there a way to reset users?
01/09 22:01:34:458[108:btpool0-6]: (mem=2882218912/3585081344) ClientManagerServiceImpl: com.tidalsoft.webclient.framework.server.util.DataRequestException:
at com.tidalsoft.webclient.framework.server.util.ReflectionUtils.feedToCollection(Unknown Source)
at com.tidalsoft.webclient.framework.server.ClientManagerServiceImpl.executeRequest(Unknown Source)
at com.tidalsoft.webclient.framework.server.ClientManagerServiceImpl.getList(Unknown Source)
at sun.reflect.GeneratedMethodAccessor804.invoke(Unknown Source)
at com.tidalsoft.webclient.framework.server.ClientManagerServiceImpl.processCall(Unknown Source)
LoginModule: Please verify uer name and password. Credential cannot connect to ActiveDirector
y[xxxxxxx] javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityConte
xt error, data 52e, v1db1
You'll need to open a TAC support case for that one. It could be that you didn't apply the hotfix, there was corruption in the database backup, a few things. It could be a quick fix, but it's too hard to say without getting more involved.
Thanks Max, yes we are waiting to hear back from cisco support.
We applied "188.8.131.525.0" patch, hope its the latest.
Thanks for the advice.
Nilaksha, Were you able to get this issue resolved with Cisco support? I am running into a similar issue after upgrading the database from 5.3.1 to 6.1.0. I am working with Cisco support but was wondering if you were able to get this fixed.
Yes we were able to migrate successfully. This is what we did,
1. Import database from old to new DB server
2. Copy TIDAL master root folder from old to new MT server
3. Run the SQL to inactive jobs
UPDATE quemst SET quemst_limit = 0 WHERE (quemst_id = 1);
4. Run the install.bin for upgrade master (make sure you use correct .bin, there is a different .bin for upgrade, bit confusing)
5. Before start master apply 184.108.40.2065, make sure new upd.xml is copied, when starting it will update the database new version.
6. Install clientmgr as a new installation on other MT box.
Hope this helps.
Correct me if I am wrong but it seems you could leverage this technique in a demo envrionment "upgrade" with everything off and/or disabled and then "transport" to a pristine 6.1 envrionment (for example DEV with a mapping file to convert to dev variables) and achive a controlled migration to 6.1 from 5.3.1. (w/ db upgrade to 6.1)
We had originally planned on doing something similar but our dev/mgmt team are looking for 100% re-write. We do have some jobs that can migrate right over. This could help control the load increase and moving a few groups at a time into "prod" form a "non-prod" environment.
This is actually how we are planning to combine two of our PRD databases into one. Upgrade both first then use transporter to move one to the other.
We have not had a lot of Transporter experience and with all the other pressing matters we haven't put so much focus on Transporter. I am hoping the Transporter fixes since the last time we looked at it will make it better once we pick it up for Phase two of our upgrade.
You may still get the alerts but you can change the system config Mail SMTP server to be a bogus server and you won't send emails at least