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
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 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:
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 http://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: http://en.wikipedia.org/wiki/Background_Intelligent_Transfer_Service
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: