Scheduling settings

Job scheduling
Limit number of parallel jobs	The default number of parallel jobs that can be executed by an agent is 10. Use this setting to allow the agent to execute a different number of jobs in parallel.
Launch timeout	Specifies the time that is allowed to elapse before an Agent needs to be started with the execution of a scheduled Job. If the Agent is unable to start the execution of the Job before the timeout expires, the Job will be canceled. For example, this option makes it possible to prevent situations in which Jobs remain scheduled on offline Agents. The default value is 1 week.
Launch window	Specifies the time period during which an Agent is allowed to execute a Job. Depending on the Scheduling option If outside launch window, the Job will fail, continue or wait for the next launch window, if it has not been executed during the launch window. For example, this option makes it possible to ensure that Tasks are executed at quiet times and not at peak times during the working day. To configure a launch window, use the mouse to select a time period and click Allow or Disallow to specify whether Job execution is allowed or disallowed during this period. To determine when a launch window starts and ends, an Agent uses it local time by default. However, you can choose to use UTC time on the Datastore instead. Behavior of launch window Jobs that are executed at a time that falls within the launch window will not be aborted when the launch window expires. Run Book Jobs in a Run Book that is executed during a time that falls within the launch window will be executed until the launch window expires: the next Run Book Job in the Run Book will fail. All system-initiated Job schedules will fail outside the launch window. This includes: Reapply change path Add/remove Agents from Teams Command line schedules Ivanti Workspace Integration Ivanti Identity Director Integration Dispatcher WebAPI schedules When an Agent is offline during the launch window, the Job will be canceled when the configured launch timeout expires. If the Agent gets online again before the timeout expires and within the launch window, the Job will be executed by the Agent. If you schedule an After every boot Job on an Agent in combination with the option If outside launch window: Wait for next window, the Job will be executed by the Agent after every reboot. If this moment falls outside the launch window of the Agent, this Job will be kept in queue until the next launch window. There is an exception to this behavior though: Suppose the following Jobs are scheduled on an Agent: Job 1: an After every boot Job that counts how many times the machine on which the Agent is running was rebooted. Job 2: a Run Book that contains a Task Reboot Computer. The Agent will first execute Job 1, and set the reboot count to 1. After this, it will execute Job 2. When the Agent reboots during Job 2, you would expect that the Dispatcher creates two new Jobs, Job 1 and Job 2. However, this is not the case: after the reboot during Job 2, the Dispatcher checks whether Jobs have already been created from the After every boot Job. If this is the case, no further Jobs are created. This behavior is to prevent Agents from entering a loop in which the Agent keeps rebooting and also applies if the option or when Agent is resumed after hibernate, sleep or standby is selected.
Update of detailed Task results	Specifies when the detailed results of Tasks are to be updated at Scheduling. On Job completion: If selected, the Datastore will first update the detailed Task results after all Tasks in a Job have been executed. This reduces bandwidth consumption, as the detailed Task results only needs to be updated once: when the Job has been executed. This is the default setting. On Task completion: If this option is selected, the Datastore will update the detailed Task results immediately after a Task in a Job has been executed. This allows you to get a real time overview of the detailed Task results while the Job is executed, but it increases bandwidth consumption.
Default schedule status	Specifies the default schedule status of new Jobs. Normally, when a Job is scheduled, it is enabled by default. In certain situations, it may be desirable to have a safety net, to prevent the accidental execution of Jobs. Scheduled: If selected, the new Job is enabled. This means that the Job will be executed at the time that was specified during Job scheduling. This is the default setting. On Hold: If selected, the Job is put "on hold". Jobs that are put on hold will not be executed until manually resuming the Job (either by right-clicking the Job in the Scheduling node and selecting Resume or by editing the Job and selecting Scheduled). This global setting also applies to rescheduled Jobs.

Limit number of parallel jobs

The default number of parallel jobs that can be executed by an agent is 10. Use this setting to allow the agent to execute a different number of jobs in parallel.

Launch timeout

Specifies the time that is allowed to elapse before an Agent needs to be started with the execution of a scheduled Job. If the Agent is unable to start the execution of the Job before the timeout expires, the Job will be canceled. For example, this option makes it possible to prevent situations in which Jobs remain scheduled on offline Agents.

The default value is 1 week.

Launch window

Specifies the time period during which an Agent is allowed to execute a Job. Depending on the Scheduling option If outside launch window, the Job will fail, continue or wait for the next launch window, if it has not been executed during the launch window. For example, this option makes it possible to ensure that Tasks are executed at quiet times and not at peak times during the working day.

To configure a launch window, use the mouse to select a time period and click Allow or Disallow to specify whether Job execution is allowed or disallowed during this period.
To determine when a launch window starts and ends, an Agent uses it local time by default. However, you can choose to use UTC time on the Datastore instead.

Behavior of launch window

Jobs that are executed at a time that falls within the launch window will not be aborted when the launch window expires.
Run Book Jobs in a Run Book that is executed during a time that falls within the launch window will be executed until the launch window expires: the next Run Book Job in the Run Book will fail.
All system-initiated Job schedules will fail outside the launch window. This includes:
- Reapply change path
- Add/remove Agents from Teams
- Command line schedules
- Ivanti Workspace Integration
- Ivanti Identity Director Integration
- Dispatcher WebAPI schedules
When an Agent is offline during the launch window, the Job will be canceled when the configured launch timeout expires. If the Agent gets online again before the timeout expires and within the launch window, the Job will be executed by the Agent.
If you schedule an After every boot Job on an Agent in combination with the option If outside launch window: Wait for next window, the Job will be executed by the Agent after every reboot. If this moment falls outside the launch window of the Agent, this Job will be kept in queue until the next launch window.

There is an exception to this behavior though:

Suppose the following Jobs are scheduled on an Agent:
- Job 1: an After every boot Job that counts how many times the machine on which the Agent is running was rebooted.
- Job 2: a Run Book that contains a Task Reboot Computer.
  
  The Agent will first execute Job 1, and set the reboot count to 1. After this, it will execute Job 2. When the Agent reboots during Job 2, you would expect that the Dispatcher creates two new Jobs, Job 1 and Job 2. However, this is not the case: after the reboot during Job 2, the Dispatcher checks whether Jobs have already been created from the After every boot Job. If this is the case, no further Jobs are created.
  
  This behavior is to prevent Agents from entering a loop in which the Agent keeps rebooting and also applies if the option or when Agent is resumed after hibernate, sleep or standby is selected.

Update of detailed Task results

Specifies when the detailed results of Tasks are to be updated at Scheduling.

On Job completion: If selected, the Datastore will first update the detailed Task results after all Tasks in a Job have been executed. This reduces bandwidth consumption, as the detailed Task results only needs to be updated once: when the Job has been executed. This is the default setting.
On Task completion: If this option is selected, the Datastore will update the detailed Task results immediately after a Task in a Job has been executed. This allows you to get a real time overview of the detailed Task results while the Job is executed, but it increases bandwidth consumption.

Default schedule status

Specifies the default schedule status of new Jobs. Normally, when a Job is scheduled, it is enabled by default. In certain situations, it may be desirable to have a safety net, to prevent the accidental execution of Jobs.

Scheduled: If selected, the new Job is enabled. This means that the Job will be executed at the time that was specified during Job scheduling. This is the default setting.
On Hold: If selected, the Job is put "on hold". Jobs that are put on hold will not be executed until manually resuming the Job (either by right-clicking the Job in the Scheduling node and selecting Resume or by editing the Job and selecting Scheduled).

This global setting also applies to rescheduled Jobs.