QUESTION:
Troubleshooting failed patch installs and failed patch scans
This article may be helpful in troubleshooting the following issues:
- Patch Scan fails
- Patch Status shows no patch data (only dashes) even after patch scan
- Patch Status shows no missing patches but you believe there should be some
- Patch Status numbers do not appear to be changing over time when you believe they should
- Patches show as Missing or Failed in Kaseya but are installed on the endpoint
- Patches show as Missing or Failed in Kaseya they are not missing according to Microsoft Update
In order to determine whether this article may be applicable to the conditions you are experiencing, view the Agent > Agent Logs > Agent Procedure Log (called a Script Log prior to Kaseya v6.1) for the specific endpoint.
Note: ensure you are reviewing the Agent Procedure log or the Script log, not the Agent log:
Locate the time of a recent Patch Scan. If you see a log entry indicating, “Patch Scan check failed using the primary data source…” this article may help to resolve the issue. If you cannot find a recent patch scan, go to Patch Management > Scan Machine, select the endpoint, and click “Run Now” to force a new Patch Scan. Once the patch scan completes, review the logs. If you do not find this error in the Agent Procedure log, this article does not apply.
ANSWER:
Patch Scan can fail to use the primary source for a number of reasons. To explain this, it is necessary to first address the differences between the primary and alternate data sources.
The Primary Data Source for patch management is the Microsoft Update Catalog. Kaseya leverages the Windows Update Agent (wua.api) to check the Microsoft Update Catalog (MUC) for all patches currently available and to determine which of those patches are applicable to the endpoint. The Kaseya UI allows you to manage which patches should be installed via Patch Policy, but Kaseya is not "deciding" which patch(es) apply to a specific endpoint.
When the Primary (online) Data Source is not available, the patch scan will defer to an alternate (offline) source. This source, Windows Software Update Service (WSUS) is a .cab file that is stored locally on the endpoint. As there is a file size limit to WSUSscn2.cab, it contains only an extremely limited number of patches - only current, active Service Packs, Security Updates, and Update Rollups. For example, where the MUC might contain 10,000, the .cab file might contain only 100. Of those, only one might potentially apply to the endpoint and if that patch is already installed (Windows 7 SP1, for example), then patch scan would not report any needed patches.
The Agent Procedure log will contain an error code indicating why the scan failed to use the primary data source. This error is Microsoft-generated and will be formatted similar to 0x00000000. You can often find some general information about the error code by searching the web.
The failure of the primary data source is generally caused by only a handful of things: firewall and/or proxy restriction, the Windows/MS update service being disabled by Group Policy (GPO), and/or the Background Intelligent Transfer Service (BITS) not being enabled on the endpoint. There are some other, less common issues the can cause this, but these three contribute to more than 95% of the failures of the primary data source.
1. Ensure the five websites necessary for patching are not disallowed by Firewall, Proxy, web filter or other security services (allow anonymous browse access to these sites). The five sites are:
The failure of the primary data source is generally caused by only a handful of things: firewall and/or proxy restriction, the Windows/MS update service being disabled by Group Policy (GPO), and/or the Background Intelligent Transfer Service (BITS) not being enabled on the endpoint. There are some other, less common issues the can cause this, but these three contribute to more than 95% of the failures of the primary data source.
1. Ensure the five websites necessary for patching are not disallowed by Firewall, Proxy, web filter or other security services (allow anonymous browse access to these sites). The five sites are:
· update.microsoft.com
· download.microsoft.com
· download.windowsupdate.com
· www.windowsupdate.com
· vsaupdate.kaseya.net
If you do not have direct access to the firewall/proxy configuration, you can verify this most of the time by logging into the endpoint using the account defined in Agent > Set Credential. Using Internet Explorer (the MS sites require IE), browse to each of the websites listed.
2. Verify MS/Windows Update is not disallowed by GPO for the endpoint or the user. Because Kaseya leverages the wua.api to compare the endpoint to the MUC, disabling the service by GPO will cause the scan to fail using the primary source. If you are unfamiliar with verifying GPO settings, please refer to https://support.microsoft.com/kb/328010 for detailed information regarding GPO settings.
3. BITS is a built-in Windows service that can be managed in the same way as other Windows services (generally accessible by right-clicking "Computer" and selecting "Manage"). Ensure the service is enabled and set to start automatically. You can find general information regarding BITS here: https://en.wikipedia.org/wiki/Background_Intelligent_Transfer_Service
4. If the patch scan error being thrown is 0x80248014 and the endpoints in question are Windows7/Server2003 orearlier, stop the Windows Update or Automatic Update SERVICE, delete c:\Windows\SoftwareDistribution, and then start the Windows Update/Automatic Update service. This error often indicates that the SoftwareDistribution folder (Microsoft's temporary patch folder, similar to Temporary Internet Files folder for Internet Explorer) has become corrupt or unreadable to WUA. The folder and any necessary contents will be recreated automatically by the OS. If you choose, you can rename the folder instead. Either way, you must stop the WUA service before making a change to the folder and restart the service after the change is complete. The windows service name is wuauserv and can be called via command line using "net stop wuauserv" and "net start wuauserv". Please refer to Microsoft documentation for further information.
If the endpoints in question are Windows8/Server2012, this is caused by Microsoft's new requirement for these products to manually opt-in to the Microsoft Update service (which is needed to run the scan against the online catalog/primary data source). Microsoft provides details here: https://msdn.microsoft.com/en-us/library/windows/desktop/aa826676(v=vs.85).aspx. Kaseya is preparing a hotfix address this. While no admin action is required at this time, VSA admins can opt to create a custom script to deploy to end machines or request end users opt into the service as a work-around until the hotfix is released.
Please check these settings, adjust as necessary, and re-run patch scan. If the scan continues to report the failure of the primary source, research the error code via a web search. Three helpful sites are:
- https://social.technet.microsoft.com/wiki/contents/articles/15260.windows-update-agent-error-codes.aspx
- https://technet.microsoft.com/en-us/library/cc720432(WS.10).aspx
If you are able to determine the meaning of the error, search the web for possible fixes. If you are unable to determine the error, or if the steps you find do not resolve the issue, please open a ticket with Kaseya Support. We will attempt to help resolve the Windows Update error.
ADDITIONAL INFORMATION:
You can sometimes find additional information regarding patch failures in the c:\Windows\WindowsUpdate.log file and/or any KB Log files that might have generated. You can access the available files either on the endpoint or within the VSA by navigating to Agent Procedures > File Transfer > Get File and selecting the endpoint.
APPLIES TO:
Patch Management
VSA (all versions)