You can schedule Windows, Linux, and Mac jobs to:
- Run immediately when enabled
- Run in or in the future - once or on a recurring basis.
Note: You can create a rollback job for Windows only.
The Patch Management module allows the creation of Run-Once and Recurring jobs. Run-Once jobs are the default type of jobs for Patching.
As an example, see the screen capture of Schedule Deployment - Windows Deployment Job
For Windows, Linux, and Mac jobs, by default, 2 types of schedules are available for a Run-Once job.
1) On-Demand - The On-Demand option lets you 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 is 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 the 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.
For Windows, Linux, and Mac 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.
Note: This option is available in the case of Windows deployment jobs only.
- You can set the job to run on the last day of the month for Windows, Linux, and Mac assets. 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.
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, you can explicitly define a very specific time zone. The specific time zone option is an offset from GMT 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.
Note: DST is honored for all types of scheduled new patch jobs. To honor the DST for existing jobs that are already enabled, you must disable them first and enable them again.
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 the job getting finished in a set duration. Setting a patch window will restrict the agent from starting 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 "Assets Responded" status only for Run-Once jobs (On-Demand and non-recurring Scheduled jobs). An On-Demand job is marked "Assets Responded" when it is Enabled. A Run-Once job (non-recurring Scheduled job) is marked "Assets Responded" after the start time of the job on the asset in the last time zone. The scheduled recurring jobs are never marked "Assets Responded".
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 executed within the patching window. If the job is not executed within the patching window, the job will time out. After the job execution is complete, the status is shown as "Assets Responded" on the Jobs page from the Jobs > Linux tab.
Note: If the Patching window is not defined, the job can run perpetually till it successfully completes or fails with an explicit error.