Systems Management Appliance – Patching Best Practices
Subscriptions
Subscriptions determine which operating system and application signatures and payloads the SMA will download from the patch feed. Restricting subscriptions to only the operating systems and applications pertaining to the environment will ensure the most efficient patching configuration and avoid unneeded disk and network bandwidth utilization.
- Activate New Patches: If this option is checked, new signatures pulled from the feed will automatically be activated upon retrieval. If this box is unchecked, new patches must be manually activated before they can be detected or deployed.
- Operating Systems Patches:
- Windows Operating Systems: Choose either a list of Windows operating systems or select “All Windows in Inventory” to automatically include all Windows operating systems detected in inventory. “All Windows in Inventory” is dynamic, and the subscription will not require adjustment when new Windows versions are detected in inventory.
- Windows 10/11 Build Upgrades: Windows 10/11 build upgrades are considered operating system upgrades, not patches. These are available from the SMA as Windows Features Upgrades.
- Mac Operating Systems: Choose either a list of Mac operating systems or select “All Macs in Inventory” to automatically include all Mac operating systems detected in inventory. “All Macs in Inventory” is dynamic, and the subscription will not require adjustment when new Mac versions are detected in inventory. As of MacOS 11 (Big Sur), OS patches are not provided by Apple anymore. Explanation here.
- Locales: Choose the appropriate locales used in the environment.
- Application Patches:
- Select the desired Publishers.
- Advanced Options:
- Classification: Type of patches that will be downloaded.
- Severity: Severity of patches that will be downloaded.
- Labels: Commonly misunderstood, utilizing labels here changes the feed subscription options from everything that fits the criteria selected above to only patches that meet the criteria and fall into an associated label. An example would be the use of a smart label defined to include all patches from publisher Microsoft. If this is the only label used, only Microsoft patches would be downloaded – regardless of other subscription settings. It is not advisable to use Labels unless the patches are to be limited to what can go into said Labels.
- Disable Windows Embedded Patches: select this option to identify Windows Embedded patches and automatically disable them. Signatures are still downloaded.
- Inactivate Superseded Patches: select this option to automatically deactivate superseded patches. When patches are inactive, they cannot be used for detection or deployment.
- Detect Disabled Patches: select this option to detect patches disabled in the SMA. This allows detection of disabled patches but not deployment.
Patch Download Settings
- Configure: this section determines how the SMA handles patch payload files (not signatures).
- Disabled: No patch payloads will be downloaded/stored at all.
- All subscribed files: This option downloads every patch payload for every signature pulled from the feed (which is based on the subscription settings). This option is the simplest method to ensure all applicable patch payloads are downloaded to the SMA, but it is the least efficient in terms of disk space utilization and database performance related to patching.
- Files detected as missing: This is the recommended option, as it only downloads payloads for patches detected missing on one or more systems. These files (payloads) are downloaded based on the feed sync Schedule.
- Delete unused files after X days: If a file (payload) has been downloaded to the SMA but has not been used in X days, it is purged at the next patch synchronization.
- Offline Update: This option is used for SMAs that do not have internet access. In order to configure offline patching, an online source must be used (2 SMAs, minimum).
- Offline Target: This option is used to specify the SMA as an offline patching server. Pressing the Upload button allows for the upload of the patches.tgz file from the Online Source.
- Online Source: This option is used to specify the SMA as an Online Source for Offline Target servers. As an Online Source, a patches.tgz file will be created after each synchronization that can be uploaded to one or more Offline Targets.
- Schedule: this section determines when the patch signature update occurs and when to trigger patch payload downloads.
- Signature: this setting determines how frequently the SMA synchronizes signatures from the patch feed
- None: patch signatures will never be synchronized/downloaded
- Every day/day-of-week at XX:XX: the signatures will synchronize every day or on a specific day of the week at the specified time. The default recommendation is every day early AM.
- On the X day of every/specific-month at XX:XX: the signatures will synchronize on the specific day of the month once per month or only in the specified month.
- Files: this setting determines when the patch payloads configured in the “Configure” section are triggered for synchronization with the patch feed
- After signature download: this is the recommended best practice option, as it triggers patch payload synchronization immediately following each signature synchronization
- Every X minutes: This is the default option, but it can cause performance issues with the default of 30 minutes. The design philosophy behind this option is that it be used along with “Files detected as missing” for signature synchronization, and with a low threshold such as 30 minutes it would allow for a Detect and Deploy task to finish within the timeout window if a new signature was detected missing in the environment.
- Download Blackout: this option allows a blackout window to be set within which any patch synchronization download will pause. This is typically used to conserve bandwidth during specified times.
Active vs Inactive vs Disabled
The status of the patch: Active, Inactive, or Disabled.
• Active: Is a patch that matches subscription settings and has not been superseded or manually inactivated.
• Inactive: Matches subscription settings, but is already superseded, or has been manually inactivated.
• Disabled: Is a patch whose definition is already on the system, but found to not match current subscription settings. Disabled patches can still be used for detection if “Detect Disabled Patches” is enabled on the Subscriptions page.
Detect vs Deploy vs Detect and Deploy
Detect:
- All patch signatures defined in the schedule are used to detect patches on each associated device.
- Does not install anything.
Deploy:
- All patch payloads for patches defined for the schedule are deployed if they have previously been detected missing on each system to which the schedule is applied.
- Allows for prompting before reboot (based on configuration).
- Task ends after first reboot, so it may take several schedule runs to completely install all patches in cases where multiple patches require reboot.
- Performs a verification after installation/reboot (if required) and reports info back to the SMA.
Detect and Deploy:
- Performs an entire routine to detect and deploy each patch completely before moving on to the next signature/payload. E.g. detect patch1; if detected missing, deploy; if reboot required, reboot; detect successful installation; move on to patch2; and so on.
- Reboots as needed without consideration for other patches. This can result in several reboots for a system missing a large number of patches.
- Requires patch download settings to be configured for very frequent synchronizations or download all subscribed files.
Maximum control and flexibility are afforded by running a detect schedule, followed by a synchronization, followed by a deploy schedule. This is the best practice approach.
Example:
- Patch Download configured as “Files detected as missing”.
- Files set to download “After signature download”.
- Patch Download Schedule set to “Every Day” at “2:00”.
- Patch detection runs at 10am and detects missing patches.
- Patch feed synchronization runs the following night and downloads payloads.
- Patch deployment schedule runs 24 hours after detection schedule.
Patch Schedule Tips
- Using the “All Patches” and/or “All Devices” checkboxes on patch schedules is not recommended. Use Smart Labels for these options to limit the schedule to only those devices and signatures that are required or applicable for a much more efficient scan.
- It is best to create separate schedules for systems of varying operating system types and versions, as the agent will evaluate every signature tied to the schedule whether it applies to the current OS or not (i.e. the agent may be running on Windows 10 and receive a signature for Windows 7; it will not perform any other work related to that signature, but it must evaluate whether or not it applies to the current OS before moving on to the next signature).
- Forcing reboot on unattended servers is not recommended. Servers often reboot on a schedule based on a maintenance window, so “No Reboot” is recommended on this type of system to allow for the normal reboot schedule. Patch schedules will show “Reboot Pending” until these systems reboot.
- “Number of Prompts” determines how many chances the user is given to snooze or reboot. If the number of prompts or the timeout is exceeded, “Timeout Action” applies. If this is set to Reboot Now or Reboot Delay, then the system will either reboot immediately or after the delay if one is configured.
- “Run On Next Connection If Offline” can cause a performance impact to the server in a large deployment if the schedule is missed by a large number of systems that may come online around the same time the following day. Example: schedule runs at noon on Saturday but is missed by 5,000 laptop users. They all login Monday morning around 8am and bombard the SMA with requests.
Troubleshooting
- Replication Shares: the best way to reduce the impact of patching on your SMA’s performance. Payloads and signatures are stored on replication shares, so the only communication between the agent and SMA directly is the patch schedule itself (XML) and the result upload from the agent. The caveat with replication shares is that if they are configured not to allow failback to the SMA and they are not at full parity with the SMA, patch schedules may fail due to missing signatures and/or payloads on the replication share.
- Patch Testing: As with any type of distributed deployment, KACE strongly recommends testing all patch schedules with small sets of systems before implementing network-wide. A deeper guide is here.
- Patch Download (Feed Sync)
- A valid license is required on the SMA for patch feed synchronization to function.
- The SMA downloads patch signatures from the KACE Catalog, but all payloads come directly from vendor repositories. The Patch Download Log on Settings > Logs will show timeout or connection refused errors if there is an issue downloading the files due to a block. Firewall/Proxy URL whitelisting may be required. URLs to whitelist are here.
- The patch feed will not synchronize if less than 10% of disk space remains free on the SMA.
- Agent paths: The agent downloads and extracts all patch files (signatures and payloads) in C:\ProgramData\Quest\KACE\patches.
