Patch Management

SECURITY  Refer to Global > Audit in Permissions.

SECURITY  Refer to Sites > Audit in Permissions.

NAVIGATION  Refer to Policies.

NAVIGATION  Global > Patches. Refer to Global and site-level patches summary lists.

NAVIGATION  Sites > All Sites > click the name of a site > Patches (left navigation menu). Refer to Global and site-level patches summary lists.

NAVIGATION  Device summary page > Patch Management card. To view the various navigation paths you can use to access the device summary page, refer to Device summary.

What are Patch Management and Patch Management policies?

Datto RMM Patch Management allows you to both control and automate the deployment of patches to your Windows devices. The main objective of Patch Management is to create a consistently configured environment that is secure against known vulnerabilities in the operating system.

Patch Management is controlled in accordance with a device's patch status through policies at the global and site levels. Individual patch installations can be configured at the device level to permit exclusions or tolerances for individual patches without needing to alter entire policies.

IMPORTANT  Only Windows Managed Agents support Patch Management. Refer to Managed and OnDemand Agents.

NOTE  Patch Management support for macOS devices is available via the ComStore component Install Updates with SUPER [MAC]. For more information, refer to macOS Patch Management.

Follow the Best practices for Patch Management step-by-step guide to learn how to use Patch Management policies and Windows Update policies for device patching configuration.

With an active Patch Management policy, the Datto RMM Patch Management process works in the following manner:

  1. Devices submit their audit data to the platform. The information includes patches that Windows Update requires.
  2. The platform runs the devices' required patches as defined by Windows Update through the Patch Management policies that target the devices. These policies can be global or site-level policies (including the ability to override global policies at the site level). The policy filters will define which patches get approved or disapproved. Refer to Patch Management policy.
  3. Individual patch installations at the device level are also taken into consideration. Refer to Device-level patch actions.
  4. The final approval list is sent back to the devices, which then download the patches during the defined Patch Management policy window. For information on the order in which patches are installed, refer to Order of patch installations.

Refer to Security and navigation for paths to the global patches summary list and the site-level patches summary list.

Click any of the following categories to filter the list by that category:

  • Installed: All of the patches that have been installed.
  • Approved Pending: All of the approved patches that will be installed during the next patch window.
  • Not approved: All of the patches that have been denied.

The table displays the following information:

Field Sortable? Description
Title

The title of the patch.
To narrow the list, click the filter icon , enter a term, and click Apply. To see the full list, click Reset.
Release Date

Displays when the patch was released.
Severity

Displays the priority of the patch as specified in Microsoft Security Bulletins. Refer to About Microsoft Update classifications.
Click the filter icon and click Critical, Important, Moderate, Low, or Unspecified to filter by the priority of the patch.
Max Size

Displays the size of the patch.
Require Reboot

Displays if a reboot is required after the patch installation.
Click the filter icon and click Yes or No. To see the full list of patches, click All.
Require User Input

Displays if user input is required during the patch installation.
Click the filter icon and click Yes or No. To see the full list of patches, click All.
KB Article

Displays a Microsoft Knowledge Base article number that is associated with the patch. Click the number to open the associated article in a new tab.
To narrow the list, click the filter icon , enter all or part of an article number, and click Apply. To see the full list, click Reset.
Total Devices

Displays the number of devices on which the patch has been installed, is approved pending, or has not been approved, depending on the selected category.
Click the number to open the Device Filter Results, which is a list of the devices. Refer to Devices. Select one or more devices and click the Row Actions icon to access a number of actions, including Patch Now. Refer to Patch Now.
  • Patch Now on the device summary page: Patch a single device using the Patch Now action button.
  • Patch Now in device lists: Patch one or multiple devices in any device list using the Patch Now action button.
  • Approve/do not approve patches on the device summary page: Mark one or more patches as Approved or Not Approved on a single device in the Patches summary list.

A Datto RMM device’s patch status is determined and represented by the platform based on a sliding criteria evaluation against the device’s last audit data submission. The platform evaluates each device’s patch data submission on a true or false basis of each possible status, as outlined below, in descending order. The first such status that is true will be the device's patch status until the next audit is submitted when the same process will take place to ascertain the device’s patch status at that time.

A device can have one of the following patch statuses:

  • No Policy: The device is not targeted by any Patch Management policy.
  • No Data: No patch audit data is available. For more information, see the process flow and explanation of steps below.
  • Reboot Required: The device requires reboot.
  • Install Error: One or more errors were encountered during the most recent patch installation run.
  • Approved Pending: The device has approved pending patches that will be applied during the next patch window.
  • Fully Patched: The device is fully patched.

EXAMPLE  If a device is targeted by a Patch Management policy and has patch audit data available, but it requires reboot, has install errors, and has approved pending patches, its overall patch status will be Reboot Required, as that is the first item to return a true value in the check results.

Process flow

In order to understand the aforementioned more clearly, it is important to understand the process that takes place during a device audit: how patch information is gathered and how that information is analyzed to determine the overall patch status for an individual device. The following process flow and explanation of steps have been designed to help you assess and determine why a particular status (for example, No Data) has been determined for a particular device.

  1. A device must be targeted by a Patch Management policy. Without a policy assigned, the platform will always determine the status of the device to be No Policy.
  2. An audit is carried out on the device. By default, it's initiated by the Datto RMM Agent but can also be requested manually. For more information about audits, refer to Frequency of audits.
  3. In the case of patch status calculation, every audit is a three-step process, regardless of how the audit was initiated. The audit data is submitted to the platform to determine the device's patch status upon completion of the following three steps:
    1. Gather device hardware information.
    2. Gather device software information.
    3. Ask the Windows Update Service via the Windows Update API to carry out a patch scan. (See step 4.)
      To learn which events trigger a patch scan at audit time, refer to Frequency of patch scans at audit time.
  4. After the Windows Update API has been called, the control for patch scanning and the resultant compiled data set is passed over to the operating system and its Windows Update Service. The Datto RMM Agent audit process will now wait as long as it takes for this scan to be completed.

    4.1. Windows Update will perform a scan for all software and drivers relevant to the OS and any installed applications supported by Windows Update. It will ask its configured source server for any pertinent software or driver information to be returned.

    4.2. Source Server for Windows Updates: Microsoft Update Servers (standard) OR WSUS (custom)
    By default (standard), a Windows operating system contacts Microsoft’s Update Servers for information about available updates and hotfixes for the enquiring device.
    However, a device can be configured (custom) to use a WSUS server or Microsoft’s own Intune service to retrieve updates and hotfixes. This will alter the source that the device connects to in order to retrieve such update information and may often differ from the information returned using Microsoft’s standard update servers.
    Therefore, it is very important to understand which source server devices are querying when running their patching enquiries. A device can only be configured to contact one source for its updates.
    If the Windows Update Service itself is disabled on a device, the query will fail and no information regarding patch data will be returned from the enquiry (that is, the device's patch status will be No Data).

    4.3. Based on the outcome and health of the information returned from the Windows Update enquiry, we can categorize the result as being Successful or Failed.

    A successful enquiry is the result of a good connection with the device’s configured source server and a successful completion of the software and driver enquiry it asks of that source. Successful completion constitutes that the Windows Update Service was enabled, the enquiry was completed, and no errors were returned.
    The returned data will most commonly consist of patches to be installed and patches currently missing. However, it is possible for no patch data to be returned following a successful scan enquiry (see 4.3 > SUCCESSFUL > ZERO in the diagram above). The two primary reasons for this are as follows:

    • It is a Windows 10 device that has been recently installed with the latest available Feature Update. Because of the nature of Windows 10 Feature Updates, all former patch history is removed and there may be no updates applicable for installation from Microsoft until the following month. As such, no patch data is returned from the enquiry and the device will have a patch status of No Data.
    • The source WSUS server is not presenting any applicable patch data to the enquiring device. This is most likely due to a misconfiguration or a fault with the WSUS server. The device will therefore have a patch status of No Data. The WSUS source server and its configuration should be assessed and addressed accordingly so as to provide information to the device when it requests patch information data.

    A failed enquiry may be the result of a number of issues. These may include:

    • Windows Update Service is disabled
    • WSUS server is unreachable
    • WSUS server is reachable but unable to service the request
    • The local Windows Update cache is corrupt
    • WinHTTP proxy settings obstruct service from contacting Windows Update when run under the system profile

    In the majority of these circumstances, an HRESULT error is thrown by the Windows Update Service and recorded by the Datto RMM Agent in the device’s activity log.

    NOTE  Windows Update error codes are, unfortunately, numerous and not always easy to decipher. We recommend researching the particular error with a view to employing a suitable resolution to address the issue and resume standard Windows Update behavior. Because these errors are environmental and not under the control of the Datto RMM Agent, troubleshooting or fixing HRESULT errors is not supported by Datto RMM.

    NOTE  All information and activity of the Windows Update Service is captured in the operating system’s WindowsUpdate.log file. For more information and how to read and analyze the log, refer to this Microsoft article.

  5. The patch scan is completed and the result, along with its associated data, is passed back to the Datto RMM Agent.
  6. The audit process is completed, and all data is compiled for submission to the platform by the Datto RMM Agent.
  7. The device audit data is sent to the platform.
  8. The platform evaluates the device's audit data against the Patch Management policy applied to the device to determine the device's patch status.

Set up a Patch monitor to get an alert when a device fails to install any patches as part of a Datto RMM Patch Management policy. Refer to Patch monitor.

To see detailed information about patch installations, check the Patch Management card on the device summary page and Patch Management reports. Refer to Patch Management in Device summary and Reports.

NOTE  On Windows 10 devices, Windows Update settings > View update history may not reflect patches that were installed by Patch Management. This list is only updated when manually checking for updates; it does not reflect activities performed via the API. From the View update history page, click Uninstall updates to view a list of patches that have been installed on the device. Patches installed by a Patch Management policy will also appear in the device's Activity Log. Refer to Activity Log. To view the device’s full update history, you can also run the Windows Update Toolkit component from the ComStore. Refer to ComStore.

Refer to Best practices for Patch Management.

Notes

Datto RMM uses the Microsoft Security Response Center (MSRC) severity for all Windows updates. You can search for a KB number in the Microsoft Update Catalog where you can see an overview of the update including the MSRC severity.

Patches are prioritized the following way:

Criterion Order
Category 1. Security Updates
2. Service Packs
3. Update Rollups
4. Critical Updates
5. Updates
6. Any remaining patches
Microsoft Security Response Center Priority 1. Critical
2. Important
3. Moderate
4. Low
5. Unspecified
Release date of the patch Most recent first, descending

Based on the above prioritization, patches are installed in the following order:

Order Category Microsoft Security Response Center Priority Release date of the patch
1 Security Updates Critical Most recent first, descending
2 Security Updates Important Most recent first, descending
3 Security Updates Moderate Most recent first, descending
4 Security Updates Low Most recent first, descending
5 Security Updates Unspecified Most recent first, descending
6 Service Packs N/A Most recent first, descending
7 Update Rollups N/A Most recent first, descending
8 Critical Updates N/A Most recent first, descending
9 Updates N/A Most recent first, descending
10 Any remaining patches N/A N/A (all remaining patches are treated as equal)

NOTE  Outdated patch data that has been in the database and unreferenced by any device for 30 or more days is removed. Patches that reappear on any device are re-added.

Updates for Windows as a service devices must be handled differently from the operating systems that came before them. For more information, refer to Patch Management and Windows as a service.

The ComStore component Install Updates with SUPER [MAC] can be used as the macOS alternative to the Patch Management policy available for Windows devices.

This component uses a third-party app made available on GitHub to download and install all pending updates on a macOS device. The device will attempt to reboot, and the end user will be notified and given options to defer the updates.

To learn how to download the component, refer to the following topics:

To learn how to use the downloaded component in jobs and policies, refer to the following topics:

Linux operating system updates can be managed using one of the following components: 

  • Apt-get Update/Upgrade [LIN] can run on Debian-based Linux distributions, such as Ubuntu.
  • Yum/Dnf Update / Upgrade [LIN] can run on RHEL distributions, such as Red Hat, CentOS, and Fedora.
  • RMMMax Linux Update Collection [LIN] can run on Red Hat, CentOS, Rocky, Debian, and Ubuntu distributions*.

NOTE  *The RMMMax Linux Update Collection [LIN] component is used in conjunction with the RMMmax integration and not intended to be run as a standalone component. For more information, visit rmmmax.com or email sales@rmmmax.com.

To learn how to download the component, refer to the following topics:

To learn how to use the downloaded component in jobs and policies, refer to the following topics: