Detect and Deploy patching jobs require a connection between the device and the appliance; they do not run offline. For more information about messaging protocol connections, see Configure Agent communication and log settings.
1. |
a. |
Log in to the K1000 Administrator Console, http://K1000_hostname/admin. Or, if the Show organization menu in admin header option is enabled in the appliance General Settings, select an organization in the drop-down list in the top-right corner of the page next to the login information. |
b. |
c. |
d. |
▪ |
2. |
A name that identifies the schedule. This name appears on the Patch Schedules page. | |||
Select Detect. The page updates to the appropriate options. | |||
| |||
To use this option, you must already have created labels or Smart Labels. See Using Smart Labels for patching. | |||
3. |
Detect all available patches. This process can take a long time. Also, it might detect patches for software that is not installed on, or required by, managed devices. For example, if managed devices use anti-virus applications from only one vendor, you might not need to detect patches for all anti-virus vendors. All Patches, however, detects all missing patches regardless of whether they are required by managed devices. To refine patch detection, set up labels for the patches you want to detect, then use the Patch Labels option. | |
Restrict the action to the patches in the labels that you select. This is the most commonly used patch detection option. To select labels, click Edit. To use this option, you must already have labels or Smart Labels for the patches you want to detect. See Using Smart Labels for patching. |
4. |
Restrict the action to the patches in the labels that you select. This option is the most commonly used patch detection option. To select labels, click Edit. To use this option, you must already have labels or Smart Labels for the patches you want to detect. See Using Smart Labels for patching. | |
5. |
6. |
No Reboot is not recommended because deploying patches without rebooting when required can leave systems unstable. Further, patches that require reboots are only shown as deployed after the reboot. | |||
| |||
Force Reboot works well with servers because they usually have no dedicated users. However, it is important to warn users that services will not be available when servers are being patched and rebooted. See Best practices for patching. | |||
Automatically reboot the managed device if no users are logged in. | |||
The message to be displayed to the user before the device reboots. For information about adding a custom logo to the message dialog, see Configure appliance General Settings with the Organization component enabled. | |||
The amount of time, in minutes, for the dialog to be displayed before an action is performed. If this time period elapses without the user pressing a button, the appliance performs the action specified in the Timeout drop-down list. When Force Reboot is selected, the timeout behavior takes into consideration the KUSerAlert and global K1000 Agent process timeouts. The global timeout, set in amp.conf through the Agent Settings page, always determines how long any agent-launched processes can run for, including the KUserAlert timeout. For example, if the KUserAlert timeout is set to two hours, and you set the global timeout to one hour, the agent will stop the KUserAlert because it runs too long. Therefore the global timeout must be set to the desired timeout that is longer than the KUserAlert timeout. This value must be set accordingly. | |||
The action to be performed when the Timeout period elapses without the user choosing an option. | |||
Postpone the reboot using a countdown. The countdown is in minutes. | |||
The number of prompts the user receives before the device reboots. For example, if you enter a value of 5, the device automatically reboots the fifth time the user receives the reboot prompt. In other words, the user can delay the reboot only four times if the Number of prompts value is set to 5. | |||
The time that elapses before the user is reprompted to reboot. |
7. |
Run daily at a specified time, or run on a designated day of the week at a specified time. | |||||||||||
Run on the nth of every month/specific month at HH:MM |
Run on the nth day every month, (for example, the first or the second) day of every month, or a specific month, at the specified time. | ||||||||||
Run according to a custom schedule. Use standard 5-field cron format (extended cron format is not supported): Use the following when specifying values:
| |||||||||||
The timezone to use when scheduling the action. Select Server to use the timezone of the appliance. Select Agent to use the timezone of the managed device. | |||||||||||
The time limit for patching actions. For example, if you schedule patches to run at 04:00, you might want all patching actions to stop at 07:00 to prevent bandwidth issues when users start work. To do so, you could specify 180 in the minutes box. |
8. |
1. |
a. |
Log in to the K1000 Administrator Console, http://K1000_hostname/admin. Or, if the Show organization menu in admin header option is enabled in the appliance General Settings, select an organization in the drop-down list in the top-right corner of the page next to the login information. |
b. |
c. |
d. |
▪ |
2. |
A name that identifies the schedule. This name appears on the Patch Schedules page. | |||
Select Detect. The page updates to the appropriate options. | |||
| |||
To use this option, you must already have created labels or Smart Labels. See Using Smart Labels for patching. | |||
3. |
Restrict the action to the patches in the labels that you select. This option is the most commonly used patch detection option. To select labels, click Edit. To use this option, you must already have labels or Smart Labels for the patches you want to detect. See Using Smart Labels for patching. | |
4. |
The options displayed to users when patch actions run. To perform the action without notifying the user, leave the Options field blank.
| |||||||
The amount of time, in minutes, for the dialog to be displayed before an action is performed. If this time period elapses without the user pressing a button, the appliance performs the action specified in the Timeout drop-down list. | |||||||
The action to be performed when the Timeout period elapses without the user choosing an option. | |||||||
The amount of time, in minutes, for the period after the user clicks Snooze. When this period elapses, the dialog appears again. | |||||||
Select the Snooze Until Limit check box to enable the user to Snooze the patch action a specified number of times. Specify the number of Attempts. | |||||||
The message to be displayed to users before the action runs. To customize the logo that appears in the dialog, see Configure appliance General Settings with the Organization component enabled. | |||||||
The message displayed to users when the patch action is complete. |
5. |
No Reboot is not recommended because deploying patches without rebooting when required can leave systems unstable. Further, patches that require reboots are only shown as deployed after the reboot. | |||
| |||
Force Reboot works well with servers because they usually have no dedicated users. However, it is important to warn users that services will not be available when servers are being patched and rebooted. See Best practices for patching. | |||
Automatically reboot the managed device if no users are logged in. | |||
The message to be displayed to the user before the device reboots. For information about adding a custom logo to the message dialog, see Configure appliance General Settings with the Organization component enabled. | |||
The amount of time, in minutes, for the dialog to be displayed before an action is performed. If this time period elapses without the user pressing a button, the appliance performs the action specified in the Timeout drop-down list. When Force Reboot is selected, the timeout behavior takes into consideration the KUSerAlert and global K1000 Agent process timeouts. The global timeout, set in amp.conf through the Agent Settings page, always determines how long any agent-launched processes can run for, including the KUserAlert timeout. For example, if the KUserAlert timeout is set to two hours, and you set the global timeout to one hour, the agent will stop the KUserAlert because it runs too long. Therefore the global timeout must be set to the desired timeout that is longer than the KUserAlert timeout. This value must be set accordingly. | |||
The action to be performed when the Timeout period elapses without the user choosing an option. | |||
Postpone the reboot using a countdown. The countdown is in minutes. | |||
The number of prompts the user receives before the device reboots. For example, if you enter a value of 5, the device automatically reboots the fifth time the user receives the reboot prompt. In other words, the user can delay the reboot only four times if the Number of prompts value is set to 5. | |||
The time that elapses before the user is reprompted to reboot. |
6. |
Run daily at a specified time, or run on a designated day of the week at a specified time. | |||||||||||
Run on the nth of every month/specific month at HH:MM |
Run on the nth day every month, (for example, the first or the second) day of every month, or a specific month, at the specified time. | ||||||||||
Run according to a custom schedule. Use standard 5-field cron format (extended cron format is not supported): Use the following when specifying values:
| |||||||||||
The timezone to use when scheduling the action. Select Server to use the timezone of the appliance. Select Agent to use the timezone of the managed device. | |||||||||||
The time limit for patching actions. For example, if you schedule patches to run at 04:00, you might want all patching actions to stop at 07:00 to prevent bandwidth issues when users start work. To do so, you could specify 180 in the minutes box. |
7. |
See Determine whether a patch can be rolled back.
1. |
a. |
Log in to the K1000 Administrator Console, http://K1000_hostname/admin. Or, if the Show organization menu in admin header option is enabled in the appliance General Settings, select an organization in the drop-down list in the top-right corner of the page next to the login information. |
b. |
c. |
d. |
▪ |
2. |
A name that identifies the schedule. This name appears on the Patch Schedules page. | |||
Select Detect. The page updates to the appropriate options. | |||
| |||
To use this option, you must already have created labels or Smart Labels. See Using Smart Labels for patching. | |||
3. |
Detect all available patches. This process can take a long time. Also, it might detect patches for software that is not installed on, or required by, managed devices. For example, if managed devices use anti-virus applications from only one vendor, you might not need to detect patches for all anti-virus vendors. All Patches, however, detects all missing patches regardless of whether they are required by managed devices. To refine patch detection, set up labels for the patches you want to detect, then use the Patch Labels option. | |
Restrict the action to the patches in the labels that you select. This is the most commonly used patch detection option. To select labels, click Edit. To use this option, you must already have labels or Smart Labels for the patches you want to detect. See Using Smart Labels for patching. |
4. |
Restrict the action to the patches in the labels that you select. This option is the most commonly used patch detection option. To select labels, click Edit. To use this option, you must already have labels or Smart Labels for the patches you want to detect. See Using Smart Labels for patching. | |
5. |
The options displayed to users when patch actions run. To perform the action without notifying the user, leave the Options field blank.
| |||||||
The amount of time, in minutes, for the dialog to be displayed before an action is performed. If this time period elapses without the user pressing a button, the appliance performs the action specified in the Timeout drop-down list. | |||||||
The action to be performed when the Timeout period elapses without the user choosing an option. | |||||||
The amount of time, in minutes, for the period after the user clicks Snooze. When this period elapses, the dialog appears again. | |||||||
Select the Snooze Until Limit check box to enable the user to Snooze the patch action a specified number of times. Specify the number of Attempts. | |||||||
The message to be displayed to users before the action runs. To customize the logo that appears in the dialog, see Configure appliance General Settings with the Organization component enabled. | |||||||
The message displayed to users when the patch action is complete. |
6. |
No Reboot is not recommended because deploying patches without rebooting when required can leave systems unstable. Further, patches that require reboots are only shown as deployed after the reboot. | |||
| |||
Force Reboot works well with servers because they usually have no dedicated users. However, it is important to warn users that services will not be available when servers are being patched and rebooted. See Best practices for patching. | |||
Automatically reboot the managed device if no users are logged in. | |||
The message to be displayed to the user before the device reboots. For information about adding a custom logo to the message dialog, see Configure appliance General Settings with the Organization component enabled. | |||
The amount of time, in minutes, for the dialog to be displayed before an action is performed. If this time period elapses without the user pressing a button, the appliance performs the action specified in the Timeout drop-down list. When Force Reboot is selected, the timeout behavior takes into consideration the KUSerAlert and global K1000 Agent process timeouts. The global timeout, set in amp.conf through the Agent Settings page, always determines how long any agent-launched processes can run for, including the KUserAlert timeout. For example, if the KUserAlert timeout is set to two hours, and you set the global timeout to one hour, the agent will stop the KUserAlert because it runs too long. Therefore the global timeout must be set to the desired timeout that is longer than the KUserAlert timeout. This value must be set accordingly. | |||
The action to be performed when the Timeout period elapses without the user choosing an option. | |||
Postpone the reboot using a countdown. The countdown is in minutes. | |||
The number of prompts the user receives before the device reboots. For example, if you enter a value of 5, the device automatically reboots the fifth time the user receives the reboot prompt. In other words, the user can delay the reboot only four times if the Number of prompts value is set to 5. | |||
The time that elapses before the user is reprompted to reboot. |
7. |
Run daily at a specified time, or run on a designated day of the week at a specified time. | |||||||||||
Run on the nth of every month/specific month at HH:MM |
Run on the nth day every month, (for example, the first or the second) day of every month, or a specific month, at the specified time. | ||||||||||
Run according to a custom schedule. Use standard 5-field cron format (extended cron format is not supported): Use the following when specifying values:
| |||||||||||
The timezone to use when scheduling the action. Select Server to use the timezone of the appliance. Select Agent to use the timezone of the managed device. | |||||||||||
The time limit for patching actions. For example, if you schedule patches to run at 04:00, you might want all patching actions to stop at 07:00 to prevent bandwidth issues when users start work. To do so, you could specify 180 in the minutes box. |
8. |
See Determine whether a patch can be rolled back.
1. |
a. |
Log in to the K1000 Administrator Console, http://K1000_hostname/admin. Or, if the Show organization menu in admin header option is enabled in the appliance General Settings, select an organization in the drop-down list in the top-right corner of the page next to the login information. |
b. |
c. |
d. |
▪ |
2. |
A name that identifies the schedule. This name appears on the Patch Schedules page. | |||
Select Detect. The page updates to the appropriate options. | |||
| |||
To use this option, you must already have created labels or Smart Labels. See Using Smart Labels for patching. | |||
3. |
Restrict the action to the patches in the labels that you select. This option is the most commonly used patch detection option. To select labels, click Edit. To use this option, you must already have labels or Smart Labels for the patches you want to detect. See Using Smart Labels for patching. | |
4. |
The options displayed to users when patch actions run. To perform the action without notifying the user, leave the Options field blank.
| |||||||
The amount of time, in minutes, for the dialog to be displayed before an action is performed. If this time period elapses without the user pressing a button, the appliance performs the action specified in the Timeout drop-down list. | |||||||
The action to be performed when the Timeout period elapses without the user choosing an option. | |||||||
The amount of time, in minutes, for the period after the user clicks Snooze. When this period elapses, the dialog appears again. | |||||||
Select the Snooze Until Limit check box to enable the user to Snooze the patch action a specified number of times. Specify the number of Attempts. | |||||||
The message to be displayed to users before the action runs. To customize the logo that appears in the dialog, see Configure appliance General Settings with the Organization component enabled. | |||||||
The message displayed to users when the patch action is complete. |
5. |
No Reboot is not recommended because deploying patches without rebooting when required can leave systems unstable. Further, patches that require reboots are only shown as deployed after the reboot. | |||
| |||
Force Reboot works well with servers because they usually have no dedicated users. However, it is important to warn users that services will not be available when servers are being patched and rebooted. See Best practices for patching. | |||
Automatically reboot the managed device if no users are logged in. | |||
The message to be displayed to the user before the device reboots. For information about adding a custom logo to the message dialog, see Configure appliance General Settings with the Organization component enabled. | |||
The amount of time, in minutes, for the dialog to be displayed before an action is performed. If this time period elapses without the user pressing a button, the appliance performs the action specified in the Timeout drop-down list. When Force Reboot is selected, the timeout behavior takes into consideration the KUSerAlert and global K1000 Agent process timeouts. The global timeout, set in amp.conf through the Agent Settings page, always determines how long any agent-launched processes can run for, including the KUserAlert timeout. For example, if the KUserAlert timeout is set to two hours, and you set the global timeout to one hour, the agent will stop the KUserAlert because it runs too long. Therefore the global timeout must be set to the desired timeout that is longer than the KUserAlert timeout. This value must be set accordingly. | |||
The action to be performed when the Timeout period elapses without the user choosing an option. | |||
Postpone the reboot using a countdown. The countdown is in minutes. | |||
The number of prompts the user receives before the device reboots. For example, if you enter a value of 5, the device automatically reboots the fifth time the user receives the reboot prompt. In other words, the user can delay the reboot only four times if the Number of prompts value is set to 5. | |||
The time that elapses before the user is reprompted to reboot. |
6. |
Run daily at a specified time, or run on a designated day of the week at a specified time. | |||||||||||
Run on the nth of every month/specific month at HH:MM |
Run on the nth day every month, (for example, the first or the second) day of every month, or a specific month, at the specified time. | ||||||||||
Run according to a custom schedule. Use standard 5-field cron format (extended cron format is not supported): Use the following when specifying values:
| |||||||||||
The timezone to use when scheduling the action. Select Server to use the timezone of the appliance. Select Agent to use the timezone of the managed device. | |||||||||||
The time limit for patching actions. For example, if you schedule patches to run at 04:00, you might want all patching actions to stop at 07:00 to prevent bandwidth issues when users start work. To do so, you could specify 180 in the minutes box. |
7. |
© 2021 Quest Software Inc. ALL RIGHTS RESERVED. Feedback Terms of Use Privacy