Windows Patch Management Troubleshooting Guide

Topic

Please see the following for some recommended troubleshooting steps in the case that you encounter an issue with Windows patch management.

Environment

• Microsoft Windows

• NinjaOne patch management

Description

• Failed to scan for patch in WSUS devices
• Failed patches
• Patch scans are running for too long
• Stop certain patches from being applied
• Windows Updates locally on the machine states my device hasn't been scanned in a prolonged amount of time
• Running a scan in Windows Updates finds available patches, even though I have patch management configured with NinjaOne
• Patch is not listed as installed in NinjaOne, but is listed as installed via WMI calls on the device

• Windows 11 upgrade is offered on Windows 10 machines

Failed to scan for patch in WSUS devices: 

Problem

For endpoints that point towards WSUS in a registry, NinjaOne missed a scan for patching in the devices. 

Cause

Possible causes include servers being unreachable, communication errors, improper configuration, or other errors. 

Solution

To check/disable WSUS locally on the device, the easiest way would be to check the following registry keys.

Under:

[HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate] 

look for:

"WUServer"

"WUStatusServer"

In both cases, confirm the value of these keys are blank.

Then go to:

[HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAU]

Look for the key called 'UseWUServer' and change it to 0, then restart the windows update service.

Please note that these keys can be set by group policy from a server where WSUS is enabled, so the keys might return; in that case the GPO needs to be disabled on the server, otherwise this setting would continue to interrupt NinjaOne's ability to patch the devices.

Failed patches:

Problem

When attempting to apply Windows patches, some of them fail to install.

Cause

The short answer here is that Microsoft patches fail for myriad reasons, including, but not limited to:

• Network interruption during scan and/or apply
• Faulty/buggy patch
• Presence of malware 

Solution

NinjaOne provides some of the most common solutions to the problem of failed patches, which you can find by clicking on the drop-down menu to the right of the patch:

In addition to these measures, you can follow these troubleshooting steps:

• Research the KB that is failing to determine if this is a known issue, and follow any resolution guidelines provided by Microsoft.
• Look at the event logs of the affected device.
• Use the Windows Update Troubleshooting tool for Windows 7, 8 and 10 boxes that are affected.

Patch scans are running for too long:

Problem

Windows patch scans are running for extended periods of time and never seem to complete.

Cause

Duration settings for scan schedules are missing or too long.

Solution

Important Note: Patch scan duration can vary from system to system. Typically speaking, a patch scan can be expected to run for up to three hours. In some cases, a check for updates can become stuck when WUA related processes or NinjaOne's patch management tool are unable to finish processing the check for updates. This can indicate a problem with wuauserv and would need to be investigated on the local machine in order to find the root cause of the problem. The instructions below are intended to address NinjaOne patch scan times and won't address any of the underlying problems with WUA that could be the root cause for Windows Update running for much longer than expected. 

In order to corral patch scan times, Windows patch management scan schedule policy settings allow for duration limits. 

To configure this, do the following in your NinjaOne console:

1. Navigate to the policy editor you'd like to set a scan duration for, and then select the Windows Patches tab.
2. Under the Scan Schedule settings, click on the current schedule to edit it.
3. Enter a time in hours or minutes for the duration.
4. Save the changes.

The same duration settings can be applied to the update schedule if desired. 

Stop certain patches from being applied:

Problem

There are some patches that I do not want to be installed on a device (or devices) that I manage.

Cause

Newly released patches can sometimes have unexpected undesirable effects on agent machines (like blue screens or application conflicts).

Solution

Situations like these call for the rejection of a patch across multiple machines that might be affected by the issue with the patch. Please see Windows Patch Management: Approving, rejecting, and uninstalling patches for more information on the options available for this.

Windows Updates locally on the machine states my device hasn't been scanned in a prolonged amount of time:

Problem

The 'Last Scan' field in the Windows Updates tool locally on a machine states that my device has not been scanned recently.

Cause

Windows Updates only updates the “Last Scan” field based on scans that were run through its application locally on the device, and Microsoft uses an .XML file to set this field. Therefore, when NinjaOne runs a Windows patch scan, Windows Updates does not detect or reflect this scan having occurred.

Solution

To confirm that your device has been running scans through NinjaOne, it is best to reference the Activity Feed first. If you do not see a recent scan (based on your 'Windows Patches' policy configurations), please reach out to Support for additional assistance in finding out why it may have missed its scan.  

Important Note: If a device is offline at the time when a scan is scheduled to occur, it will not make up the scan unless this feature is enabled:

Running a scan in Windows Updates finds available patches, even though I have patch management configured with NinjaOne:

Problem

When I run a patch scan locally on a machine through Windows Updates, it is finding available patches. NinjaOne should be handling updates through the Windows patch management tool that I have configured.

Cause

The following are a few examples as to why the Windows Updates mechanism locally on a machine may be picking up available patches:

1. The last update cycle ran through NinjaOne was missed.
2. Since the last update cycle ran through NinjaOne, there have been patches made available and NinjaOne has not run its next update cycle yet.
3. You are in between your scan cycle and update cycle and those patches haven’t been applied.  
4. Windows Patch Management is unable to update until the device is rebooted.
5. Patches have been rejected for NinjaOne's patch management tool, either manually or per the approval settings configured for your policy.
6. There are Windows patch management failures on the machine. 

Solution

The following are solutions that pertain to the potential causes listed above, respectively:

1. Check the Activity Feed for the device in question to confirm if the most recent scheduled scan was missed. The scan may have been missed if the device was offline at the time when the scan was scheduled to run. For more information about why the scan was missed, please open a ticket with Support. 
2. This is normal to see if you run monthly updates on a device, as Microsoft comes out with patches every Tuesday.  
3. Check the device in question to see if there are any updates listed under the 'Pending' or 'Approved' sections.
4. If there is a pending reboot on the device due to Windows patch management, it will not be able to update until a reboot has occurred.
5. Check the device in question to see if there are any updates listed under the 'Rejected' tab. Patches listed here will not be installed by NinjaOne's Windows patch management tool, but will still show up as available patches locally on the machine during a Windows Updates scan.
6. Please see the Failed patches section above.

Patch is not listed as installed in NinjaOne, but is listed as installed via WMI calls on the device:

Problem

A specific patch does not show as installed under Device > OS Patches > Installed, despite verifiably existing on the device as installed via Windows Management Instrumentation (WMI) calls.

There are various ways to query installed updates on a Windows machine. Results from different methods can vary greatly depending on what is being queried. This TechNet article offers some insight on methods used in this documentation.

NinjaOne UI:

WMI Query:

In the above screenshots, installed updates as listed in the NinjaOne UI are shown compared to installed updates as queried via WMI. As you can see, there are updates on both sides that are not listed via the other method. Specifically, KB4524569, KB4528759, and KB4528760 are shown as installed via the WMI call results, but are not shown as installed via the NinjaOne console. Inversely, KB4533002, KB4530684, KB4528760, KB2267602, KB4052623, and KB890830 are shown in the NinjaOne console but are not listed in the WMI call results.

Cause

This occurs due to the ways each method queries for the installed updates. NinjaOne is querying for updates that are installed using Windows Update, Microsoft Update, Automatic Updates, WSUS, or ConfigMGR, which are generally installed using a Microsoft Installer (MSI). Installations of these packages are recorded in the Software Distribution datastore and the registry. Therefore, querying these locations will provide a list of the installed updates contained. NinjaOne currently queries these locations to gather installed patch information.

WMI uses the Win32_QuickFixEngineering class, which only returns updates supplied by Component Based Servicing (CBS). These updates are typically small, system-wide updates commonly referred to as quick-fixes or hotfixes. Click here for more in-depth information about this.

Important Note: Microsoft may have lists of which specific KBs are installed by which methods. However, we cannot provide this information, as it may be subject to change at Microsoft's discretion.

Solution

In short, since these updates are not listed in the registry, they cannot be queried by NinjaOne in order to verify their existence at this time. Further, in some instances, an update may be installed via an upgrade to the OS (ie, 1903 or 1909) and remain dormant on a system as specified in this Microsoft article.

In the specific case of KB4528759/KB4528760, Microsoft has packaged the update into upgrade packages for Windows 10 to the current build of version 1903 (18362.592) and version 1909 (18363.592). Therefore, the build number of the current operating system installed on the agent machine is key in identifying if KB4528759/KB4528760 is installed.

If the issue you are experiencing is not listed above, or if you need further assistance after attempting the recommended troubleshooting steps, please contact NinjaOne Support.