Patch impact analysis (2019 and newer)

When patching devices, it can be hard to know what files and applications a patch affects. Patches that break what they are patching or that affect other applications are a critical concern. What if you had a simple way to determine what devices in your organization are affected by a patch? What if you could easily create an optimal pilot group for a set of patches based on how likely devices in that group will be affected by those patches? With patch impact analysis, introduced in Endpoint Manager and Security 2019.1, you can do all of these things.

Patch impact analysis relies on the client user feedback agent, which is disabled by default. This agent enables real-time monitoring of file changes and deletions made by patches. It detects application crashes and reports that data to the core server. It also has an optional client-side user interface so users can manually report application crashes.

Patch impact analysis requires a learning period that helps it work more effectively. Enabling the client user feedback agent on as many devices as possible accelerates the learning period.

End users have to run applications that get patched on their devices for the technology to learn and determine dependencies between applications and patches. For the impact analysis algorithm to make more accurate predictions, users will have to report a broken application or the technology needs to auto-detect a crashed application due to a patch.

  1. Click Tools > Configuration > Agent Configuration > Distribution and Patch. Double-click an existing configuration or right-click and create a new one.
  2. Select the User Feedback page, and enable Allow the user to report broken applications. If you want to Hide the user interface on managed devices, select that option too.
  3. Click Save.
  4. Deploy the updated agent setting.
  1. In Tools > Security and Compliance > Patch and Compliance, select the patches you want to analyze. You can select a single patch or multiple patches. Right-click the selected patches and click Patch Impact Analysis.
  2. In the Patch Impact Analysis window, add the devices that you want to analyze. Do this by selecting a target category and clicking the Add button.
  3. Click the Calculate Risk button. This calculation may take some time.

  4. After the risk is calculated, the Best pilot group tab shows which devices among the ones you selected are most likely to be impacted by the patches. Among other factors, the impact is calculated by the presence of affected files or applications. Based on the analysis, each device shows the calculated risk factor. These risk factors are described later in this section.

  5. Double-click a device to see more details.

  6. For a summary of all affected applications, click the Applications at risk tab. Use the Hide applications that have 0 machines unpatched option to filter the list so it only shows affected applications.
  7. On the Best pilot group tab, click the Suggest pilot group button to generate a recommended list of devices to be part of a pilot group. This pilot group can be used to test the selected patches. Once you've clicked the button, the button label changes to Show all, and you can toggle between views.
  8. Select the devices you want for your pilot group, right-click the selection and click Generate a repair task.
  9. The Patch and Compliance repair task dialog box opens. It includes the devices you selected to be patched and the patches to apply.
  10. Run the repair task and monitor the affected devices. The Patch and Compliance tree's Broken applications and Reported bad patches items can help you do this.

The patch impact analysis assigns risk factors to the devices you selected. Generally, you should focus your testing efforts on critical risk factors first, followed by those with a high and medium projected risk.

These are the risk factor levels:

  • Medium: At least one of the selected patches has a direct impact on this application, but the user feedback agent hasn't collected any reports of the selected patches breaking this application. Since there is a direct dependency between the patch and the application, it's advised to test this application before deploying the patch.
  • High: There was a crash report for an impacted application or a user reported patch misbehavior, but the report was on another patch in the same family. For example, a user has previously reported that the Java patch, JDK8-211_INTL, is breaking application X, but the patch impact report is analyzing the impact of patch JDK8-212_INTL (i.e. a different Java patch) on the same application X. Since the patch impact analysis algorithm is aware that a previous patch broke the application, it's highly recommended to test the same application with the new patch.
  • Critical: The patch impact analysis algorithm has determined that there was a previous crash reported for an impacted application, either automatically by the user feedback agent or manually through the client user feedback application. Since this application was already reported as being broken by a patch, it is critical to test other devices that have the same application before you patch.
  • Unknown: The application was detected by inventory as being installed, but the analysis didn't find any dependency between this application and one of the selected patches. Usually this results in low or no impact.