SECURITY Refer to Global > Audit in Permissions.
SECURITY Refer to Sites > Audit in Permissions.
NAVIGATION Refer to Policies - New UI.
NAVIGATION New UI > Global > Patches. Refer to Global and site-level patches summary lists.
NAVIGATION New UI > Sites > All Sites > click the name of a site > Patches (left navigation menu). Refer to Global and site-level patches summary lists.
NAVIGATION New UI > 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 - New UI.
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.
1. Disable Automatic Windows Update
If you would like to use a Patch Management policy to install only the patches you have approved, and to make sure that the Patch Management process is not interfered with, you need to disable Automatic Windows Update on your devices. We recommend that you create a Windows Update policy in Datto RMM to achieve this. For more information, refer to Windows Update policy.
2. Set up a Patch Management policy
You can then set up a Patch Management policy to ensure that you install the necessary patches on your devices. Refer to Patch Management policy.
3. Device audit and patch installations
With an active Patch Management policy, the Datto RMM Patch Management process works in the following manner:
- Devices submit their audit data to the platform. The information includes patches that Windows Update requires.
- 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.
- Individual patch installations at the device level are also taken into consideration. Refer to Device-level patch actions.
- 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:
|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.
|Displays when the patch was released.|
|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.
|Displays the size of the patch.|
|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.
|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.
|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 - New UI. Select one or more devices and click the Row Actions icon to access a number of actions, including Patch Now. Refer to Patch Now.
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.
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.
- 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.
- 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.
- 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:
- Gather device hardware information.
- Gather device software information.
- 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.
- 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.
- The patch scan is completed and the result, along with its associated data, is passed back to the Datto RMM Agent.
- The audit process is completed, and all data is compiled for submission to the platform by the Datto RMM Agent.
- The device audit data is sent to the platform.
- 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 - New UI and Reports - New UI.
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 Retrieve Windows Update History component from the ComStore. Refer to ComStore - New UI.
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:
|Category||1. Security Updates|
|2. Service Packs|
|3. Update Rollups|
|4. Critical Updates|
|6. Any remaining patches|
|Microsoft Security Response Center Priority||1. Critical|
|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)|
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: