Tasks

A task or job is an object that is configured to run a command or script against the managed host that is executed based on a policy.

These tasks can allow for elevated job execution by securely sharing this record (but not the password) with a user that would typically not be permitted to run such a command.

For example, allow a least privileged user the ability to reset a password without providing them direct Administrative or Root access or the password required for each. 

Alternatively, a task can be configured to automatically rotate a password every set time period or based on a user action like Unlock or Check-in.

Tasks can be unique to record types (i.e. a different task for Windows vs Unix endpoints) or it can unique to records themselves (i.e. a different task for each Windows endpoint).

 

To define your tasks on a record type, you will need to have the System Administrator role.

Once logged in with your System Administrator account, navigate to Administration > Record Types and then click the Edit button next to the record type you wish to update.

Next, click the Tasks button to open its configuration page. Make the required changes to the tasks list and then click the Save button to finalize the update.

To define your tasks on a record, you will need to have the Task Control: Manage role for this record. Once logged in, view the record, select the Manage > Tasks option and then the Make Unique button on its configuration page to break the Task inheritance from the record type.

Make the required changes to the tasks and then click the Save button to finalize the update.

Tasks consist of several components and all can be configured as required.

Creating Tasks

To Add a new task to either a Record Type or a uniquely tasked Record:

1. Open the Record Type’s Task menu (Task button) or the Record’s Task menu (Manage > Tasks) and click the Add Task button.

2. Select the script that will be executed against the record when the task is executed. For example, the script Password Reset Remote Windows will reset the password of the User defined in this record using the Host.

3. Check one or more Policy Event options. The Event options define when the task’s Script will be executed. For example, selecting Every Sunday means the script will be executed against the record every Sunday (once a week).

4. Click the Save button to complete the task creation process.

Edit or Remove Tasks

To Edit or Remove an existing task on either a Record Type or a uniquely tasked Record:

1. Open the Record Type’s Task menu (Task button) or the Record’s Task menu (Manage > Tasks).

2. For the task that needs to be edited, select the required option from its Actions menu.

Edit Policy	Use this option to select a different script or to update the selected Events.
Edit Script	Use this option to edit the script.
Remove Task	Use this option to remove the task entirely from this object.

3. Click the Save button afterwards to complete your edit.

Target Record

Target Record parameter defines which record should be used to schedule a job with the selected script for this task.

Possible values are:

• Record Itself - the job will be scheduled for the record itself. This is the most typical choice for the majority of situations.

  Note that for the password reset jobs if the record references another record then the referenced record password will be updated after successful job execution.

• Referenced Record - the job will be scheduled for the referenced record if it exists in this record definition. The scheduling process will select the task in the referenced record by the name of the script. If the task does not exist the job will be scheduled for the record itself. This option could be used to support the case when the task should be triggered following events that occur with the main record. However, the job should be executed using the configuration and environment of the referenced record.

• Shadow Record - the job will be scheduled for the shadow record if it exists in the task list. The scheduling process will select the task in the referenced record by the name of the script. If the task does not exist the job will be scheduled for the record itself.

Policy Events

A Task’s Policy Event determines when the script will be executed. For example, if you want to rotate a password every time a user Checks-in a record or simply every Friday, then that Check-In action or Every Friday time period is the policy event that triggers the password rotation.

The following is a list of available Policy Events that can be configured for Task execution:

After Approval	This event is triggered after the applied record is approved by a user or system administrator.
After creating or updating a record	This event is triggered after the applied record is initially created or after it is updated, either by a user or system interaction.
After Expire	This event is triggered after the approved workflow time expires on this record.
After Check-In	This event is triggered after the approved workflow is checked in on this record.
After Session	This event is triggered after an active session on this record is completed.
Check to defer execution until completion of the last active session	When enabled (checked), the event will only trigger when the last active session is completed. This includes all concurrent sessions on this single record or any other record if it is configured to use a Reference Record. In the case of reference records, the logic will check all records that use this reference and only trigger the policy when the last of all possible sessions has completed.
n minutes after unlock	Enter a numerical value for this event defined in minutes. The event is triggered this many minutes after a record’s secured field is unlocked. For example, 60 minutes after the password field is unlocked, it will be queued for rotation.
Every nth day of each month	Enter a numerical value for this event defined by the day of the month. This event is triggered on this day each month. For example, the 20th day of every month the password will be queued for rotation.
Every <selected day>	Select a day of the week. This event is triggered on this selected day every week. For example, every Sunday the password will be queued for rotation.
On Demand	This task will be made available in the record’s Execute menu and can be initiated when needed by a user with the required permissions.
Every nth day	Enter a numerical value for this event. This event is triggered every n number of days. For example, every 1 day (i.e. every day), the password will be queued for rotation.
Every x to y days	Enter a numerical value for the start and end day of this event. This event is triggered on a random day between your two defined values. For example, for every 15 to 30 days, the password will be queued for rotation on a random day between the 15th and 30th day of each interval.

Shadow Account

A Shadow Account is a secondary account used to connect to the remote computer on behalf of the primary record account to perform the designated tasks.

A common scenario is that a user cannot reset a password however the Admin or root account can, so that will be used instead.

Normally the record account is used to connect to the remote computer to execute scripts.

When a shadow account is specified for the task the script is executed under the shadow account privileges although it still has access to the main record account.

Shadow Account credentials are stored in a separate record, so when configuring your Shadow Account to be used in a Task list you must select this other record.

Time Window

The Time Window allows you to confine Task or Job executions to a specific time window.

For example, this option can be used to limit periodic job executions to off-peak hours as to not interfere with the main function of the remote devices (i.e. maintenance windows).

The time window is specified using the popular CRON format, but it also includes a visual builder for CRON expressions if you are unsure of how to write this format yourself.

Reviewing Job Results

A Job History report is provided so that the results of all jobs can be reviewed and actioned. This Job History report will include all jobs that are scheduled or have previously executed, including their events, timestamps, results, state, actions and details.

The Job History report can be accessed on an individual record by clicking the Job History button so that only jobs that pertain to this record are included. It can also be accessed globally (Reports > Job History) so that all jobs across all records can be reviewed on a single report.

On the Job History report, additional Actions can be executed:

Run	For Scheduled jobs configured to run on the local node only (i.e. not deferred to a remote worker node), click the Run button to send this job to the queue. If the job is configured to run on a remote worker node, the Run button will result in an error message indicating this remote node configuration and the task will not be executed.
Cancel	For Scheduled jobs only, click the Cancel button to cancel the execution of this job by removing it from the queue.
Details	For Completed or Error state reported jobs, click the Details button to see the detailed results of this executed job.

Fallback Jobs

Fallback execution can be enabled globally which instructs the Job Engine to repeat previously failed jobs.

System Administrators define both the frequency and total cycles of the fallback processing for the entire system.

Jobs that are reprocessed due to this fallback mechanism will be shown in the Job History report with the type Fallback.

More information about Fallback Jobs and configuration options.