Changing the Scheduler Task List Location

Manage a common Scheduler Task List from multiple machines/accounts

You can change the location of the Scheduler Task List to, for example, allow multiple Server account users on different machines to manage and edit tasks in a common Task List. The Task List is a single XML file, called config.xml, and its location path is speciified in the installconfig.properties file located in the installation directory.

Note: On Windows 7, a typical 64-bit Omniscope installation directory will be Users > {Account Name} > App Data > Local > Visokio Omniscope app >

------------------------------------------------------------------------------------------

To change the location of the Server Task List: 

1. Using a Text Editor like NotePad running in Administrator mode, open the "installconfig.properties" located in the installation directory.

2. Copy part of a line starting with #ADDITIONAL_JVM_ARGS=

3. Remove the comment # in front and add the following property after the ="-DschedulerConfigLocation="{full path to new location}\config.xml" 

For example:  ADDITIONAL_JVM_ARGS=-DschedulerConfigLocation="\\fileserver\...\scheduler\config.xml"

4. Save the modified "installconfig.properties" file. 

If the Scheduler will be running as a Windows Service (i.e. with no user login/logout account, always running so long as the machine is running), you must also add to the service wrapper configuration file:

4a. Update wrapper.conf with this change as follows:

1. Open installation folder\service\wrapper.conf.
2.  Find this line
             #wrapper.java.additional.1=
3. Remove the # in front and replace with this line 
    wrapper.java.additional.1=-DschedulerConfigLocation={full path to new location}\config.xml  

        4. Save modified wrapper.conf .

5. If you already have the Scheduler running as a Windows service, stop the Scheduler or Windows services and restart them for the above changes to take effect.

6. Also, you will need to restart Omniscope if you have an instance of Omniscope open. 

--------------------------------------------------------------------------------------- 

Now all Server Scheduler accounts sharing the same Task List will be pointing to the same (mutually accessible with read/write privileges) folder location and all these installations will share a common Task List file.

Common use cases for shared Task List locations include allowing more than one user to administer the Task List without sharing logins and passwords, ensuring 24/7 coverage of the Task List by multiple employees in multiple locations around the world, and allowing Windows-based staff with a spare Server key giving them the Scheduler interface to manage the Task List running on a 'headless' Linux server, which cannot display the interface. If you are running Server Edition 'headless' on Linux, the Scheduler interface can only be managed from a Windows machine running a spare Server license, and the resulting edited XML Task List file shared or copied across to the headless Linux Server for continuous automated execution. Note that each user administering a shared Task List must have a spare Server license on their installation in order to see the Scheduler Task List administration interface. 

Access to the Task List XML file location is a single point of failure for 24/7 automation file refresh and delivery, and the Task List config.xml file should be replicated to UAT and Failover/DR machines as part of ensuring resiliency. 

======================================

By separate licensing agreement, it is possible to enable activation of the Server license on multiple User Accounts on a single server machine (this option is known as system-wide activation). This option is usually used in cases of clustered servers, but can also be used in cases where there are multiple Task List Administrators among the Omniscope users sharing the same machine without sharing an account. Given that multiple users on the production machine increases the risk of the machine crashing, this 'workgroup' configuration is not recommended for very time-sensitive automated solutions.