Can we install an orchestrator on a new system and point it to an existing PAM database or copy an existing Orchestrator tables into a different Orchestrator's database?
Process Automation - 4.3 and above
There is no supported method to install or use a separate orchestrator against an existing set of tables and have the product work correctly.
There are many references to the original orchestrator's ID and its hostname throughout the product and database which cannot be updated. Our best attempts to make this work involve changing the 'new' orchestrator's ID to be the original orchestrator's ID. There have been published processes on this including in this KB which over time failed more often than succeeded and generally led to a large amount of time both for the client and support to attempt to get it working. Many of these cases ultimately resulted in the database being dropped in the end anyway.
Due to this it was determined using an existing set of tables in a different orchestrator is not supportable. The original information from this KB is included below in the Additional information area for reference purposes only.
To move to a new server our recommended paths are:
1. Setup a cluster node on the new server. Once confirmed that the new node is fully functional shut down the original Orchestrator.
This will copy Configuration tab settings and connectors and any instances that were assigned to run on the original orchestrator will be reassigned to complete on the new orchestrator once the original is no longer available.
You will need to
a. review the configurations \pam\server\c2o\.config\OasisConfig.properties and \pam\server\c2o\bin\c2osvcw.conf (c2osvcd.sh Unix\Linux) and migrate any configuration to the cluster node over such as memory allocations from c2osvcw.conf.
b. point any external references, such as from Service Desk, to the new hostname.
2. Install the new Orchestrator against a fresh set of database tables. Then export your library from the old Orchestrator and import into the new Orchestrator.
You will then need to:
a. Import any connectors
b. Manually migrate any Configuration tab settings
c. Manually migrate any configurations from \pam\server\c2o\.config\OasisConfig.properties and \pam\server\c2o\bin\c2osvcw.conf (c2osvcd.sh Unix\Linux)
d. Manually rebuild any schedulers
c. point any external references, such as from Service Desk, to the new hostname.
As described above this process is provided as is for reference purposes only. These steps fail more often than they succeed, and support will be recommending one of the above options.
This process is not supported for in-flight processes. Running processes contain links to the current Orchestrator and therefore may not continue to process after migration to a new host. All running processes should be aborted before following these steps.
Each PAM engine has a unique ID that it creates and writes to the database.
If you attempt to install a new Orchestrator against existing tables, it will display an error with the message "The Runtime Database is being used by another orchestrator.". This document walks through modifying the PAM configuration files so they match the DB. This process is not supported for existing in-flight process instances.
You can get the Orchestrator ID from the "properties" table in the database - You'll need this value to update the various config files so copy it out somewhere and mark it "Original ID". It will look something like d98853b2-ecbd-4d37-b71c-ecf7b46c17c4
Then install PAM against a dummy database and get it all patched up and running against this dummy database. They should use the same Database Host, Username and Password, only specifying a different database name such as "PAMDummy".
Stop the PAM service or application.
Open the NodeConfiguration file from the new install and make note of the nodeID. You will need this shortly, copy it out an mark it "Dummy ID".
Then go through the following files replacing the current "Dummy ID" with the "Original ID" from the properties table in the database.
Note: It is not called nodeid outside the nodeconfiguration file, you will have to search for the actual "Dummy ID" string to find it.
Finally, in Oasisconfig.properties, review the various database 'dbname=' values and change all of them from "PAMDummy" to the name of the original database.
If everything goes well, PAM should start against the old tables.