Scheduling Jobs

You can schedule a (deployment and rollback) job to run immediately (when enabled) or in the future - once or on a recurring basis. The Patch Management module allows creation of Run-Once and Recurring jobs. Run-Once jobs are the default type of jobs for Patching.

chedule patch deployment

Run-Once Jobs

By default 2 types of schedules are available for a Run-Once job.

1) On Demand - The On-Demand option allows you to install the patches immediately once the job is created and enabled.

2) Scheduled - The Scheduled option allows you to install the patches later at a set time and are generally used for planned one-time activities. Such jobs will begin executing, as soon as they are enabled on the server side. However, the patch installation on the assets will happen only at the scheduled time or later. For Run-Once jobs, patches installation/upgrade on assets begins only after scheduled time of the job and manifest reaching the agent. Run-Once jobs have NO end time except if a patching window is defined. That means the job will be active as long as the patches installation is not attempted on all the assets added to the patch job.

Note: Run-Once jobs when saved/created in the Enabled state, CANNOT be disabled or edited. They can however be Deleted.

Recurring jobs

Scheduled recurring jobs can be created by selecting the "Recurring Job" check box next to the Start Date. The start date and time when the job will repeat can be fine tuned for subsequent runs. Recurring jobs can be scheduled to run Daily, Weekly or Monthly.

1) Daily - Select this option to schedule the job to run once every day of week, whether a working day or weekend (since security is a 24x7 business priority).

2) Weekly - Select this option to schedule the job to run one or more day(s) of the week.

3) Monthly - Select this option to schedule the job to run on a specific date or day of a specific week.

- You can select the Patch Tuesday option to install patches for Windows assets that are released on a Patch Tuesday. For more information, see Scheduling Patch Tuesday Jobs.

- You can set the job to run on the last day of the month. This ensures that the job runs on the last day irrespective of whether the month has 28, 29, 30, or 31 days.

- Avoid the job start time between 12 AM to 3 AM. Due to our 3 hours lookup interval (we send job definition file 3 hours prior), the job might not be triggered for execution at the desired time.

Note the following important points:

- Recurring jobs do not have end-date and it will run perpetually until you disable the job that is, revoke its execution. You can Disable a job that is, Revoke its execution any time. Similarly, you can Re-Enable a job again as needed. Recurring jobs can be Enabled & Disabled any number of times.

- For Linux patch jobs, even if the reboot is not complete, the patches that are previously installed and required a reboot will be marked as already installed in next recurring job run.

Time Zone

1) When creating jobs, you should be mindful of the time zone. By default, the schedule time is interpreted as the local time (zone) of the endpoint/asset. This option is best suited for larger organizations, spread across geographies with time zones of the assets associated with a job are varying i.e. across multiple time zones. This would effectively stagger the job execution as per the local time zone of the agent.

If an organization is NOT spread across geographies OR consolidated in one time zone only, the default Agent time zone will be as good as the Server time zone schedule. This is like enforcing a schedule relative to the time zone of the server.

2) The second option is to schedule a job at a specific time zone, irrespective of the agent and server time zones. With assets spread across multiple time zones and complications like DST, etc, you can explicitly define a very specific time zone. The specific time zone option is an offset from GMT which does not change during DST or other adjustments, allowing you to run the job on all assets at a specific time.

Tip: You should select the time zone and consistently use the same settings across all jobs to reduce conflicts across multiple jobs.

Patching Window

A Patching Window is generally defined to enforce time-bound execution. Set the patching window to avoid:

1) interference/impact of patching during some important event.

2) perpetual running of the job resulting in job getting finished in a set duration. Setting a patch window will restrict the agent to start the job within the specified patch window (e.g., start time + 6 hrs). The job gets timed out if it does not start within this window. The default Patching window is perpetual i.e. Patch Window (Duration/ End time) is set to None. Setting no patch window allows the Cloud Agent to take the time it needs to complete the job.

Note that the job may time out if the asset is Offline or the Cloud Agent does not have sufficient time to download the patch after the asset comes Online. We show Completed status only for Run-Once jobs (On-Demand and non-recurring Scheduled job). An On-Demand job is marked "Completed" when it is Enabled. A Run-Once job (non-recurring Scheduled job) is marked Completed after the start time of the job on the asset on the last time zone. The scheduled recurring jobs are never marked Completed.

The Patch Window can be set between 30 minutes to 168 hours or 10080 minutes, which is 1 week. More than a week is contradictory to the very concept of a Patching window. Any job failing to start within a week, should be marked as failed and retried later, if needed. If you think you would like it to be more than 168 hours, we would suggest you turn off the "Patch Window" option itself, by changing it to 'None'.

For Linux jobs, the job must be completed within the patching window. If the job is not completed within the patching window, the job will time out.

Note: If Patching window is not defined, the job can run perpetually till it successfully completes or fails with an explicit error.