This is forked from the discussion in /collaboration/zenworks/zpm/f/patchmanagement/201196/recent-patches-showing-not_applicable, per request from . I had replied (a week or three after the final other post in that thread) reporting that I am experiencing what from its symptoms seems to be the same issue, but based on that discussion it might actually be different under the hood.
To recap some of the information from there, and add more:
My organization is running ZENworks 2017 Update 4 on the servers, although nearly all of the clients are still running the 11.4.3 client.
For some undetermined number of months now, certain machines in our fleet have been failing to detect newly-available patches as being applicable - at least initially, and quite possibly permanently. This has been a minority of computers, but enough to be noticeable as a problem. The exception has been that patches which are of a "Software Installer" priority seem to be detected as applicable without issues - which is not useful to us, since we don't install software through such patches, because we need to be able to apply install-time customizations which are not possible with that method.
With the March patches, the problem has become apparently universal. It seems to be affecting every single computer we manage.
In the cases where I've examined this directly, it has usually seemed as if the *.ospx files which I gather contain the patch-applicability definitions have not been becoming updated. More on this below.
In cases where I observed this behavior on a virtual machine, nothing I did seemed to result in the patches becoming detected as applicable, but if I then restored a pristine image (built months prior to this problem having first manifested) into that same VM the resulting system - connected to a new, separate, workstation object in ZCC - would detect the patches without issues.
I have attempted to troubleshoot this by enabling the verbose logging described in https://support.microfocus.com/kb/doc.php?id=7014131 and examining the resulting log files for detection information regarding a specific patch (released on March 9th, more than two weeks prior to the date of the troubleshooting) which we expect to want to deploy. As far as I can tell, most of the log files do not contain any reference to that patch. debug*.log and *.state do mention it, but only to report that detection failed, without anything to indicate how that detection was carried out; none of the others seem to show any sign that the patch exists. Also, the "Discovery Agent" Registry location referenced in that KB item does not contain any readily identifiable reference to the patch in question.
On several of the machines where I've attempted to troubleshoot this, I've observed that the *.ospx files which seem to contain the patch-applicability definitions have had timestamps which predate the release of the patches which are not being detected. Nothing I've tried, that I recall, has been able to get these files to be updated; even deleting them and trying to verify the DAU bundle just results in the scan running without sign of errors, and without the files being put back into place.
On one machine (the one where I'm typing this), these files have timestamps from today and yesterday, but the detection-failure behavior is still occurring. When I ran the lm_detection_x64 verbose-logging command from the above-linked KB item, I noticed that files began to appear and disappear in the tmpScan\lm.detection.cache\ directory (which is normally empty, if present at all), with names corresponding to the *.ospx files but with the file extension '.lmd' - and these files had timestamps from February 23rd, one month ago yesterday, well prior to both the dates of the *.ospx files and the dates of the updated patches which are not being detected.
In the thread from which this one is forked, it was suggested that I download the MSU for the most recent applicable Servicing Stack Update and apply it on selected machines by hand, then re-run the scans and see whether anything had changed. Results were somewhere between negative and mixed, with a stopover at inconclusive; on one machine (for which only two non-Software-Installer patches were listed as applicable, neither of them cached) the update and re-scan changed nothing, on another (for which I had forgotten to check the exact set of available patches prior to the scan), after the scan there were patches shown as applicable which dated from as far back as July of 2020 and as recently as February, but the patches released in March still did not show as applicable.
(As I write this, it occurs to me that I did not rename the SYSTEM_HASH Registry entry on at least one of these computers prior to the re-scan. I do not know whether this might have affected the results.)
Any suggestions for things to try, or should I open a SR about this for more in-depth and hands-on analysis?
Support
Documentation
Learning Services
Partner Programs
