Is there a way I can refresh the patch status for some or all PCs in the Device List? Yesterday I upgraded a couple PCs to Windows 10 and ran update manually to make sure they were all up to date, but ITSM still shows there are pending Windows 7 patches. I know this will probably fix itself in a day or two, I’m just wondering if there is something I can do or a procedure I can run that will refresh ITSM’s “patch data” on a specifc device or devices.
Sorry; yes, I tried Refresh Device Information, refresh software inventory as well. Rebooted a couple times, etc, it doesn’t seem to refresh the patch info. It’s weird, sometimes it seems to update right away for other machines I’ve updated manually (ie to Windows 10), and other times it takes longer; though this is the longest I’ve ever seen it take (24 hours ish) still showing it needs windows 7 patches even though in the Device Summary tab it knows it’s Windows 10 Pro.
It seemed to make no difference on the one PC, on the other I don’t see anything in Execution log even though it’s online and I ran it a couple of times. (do you want the machine names to investigate in my account? I can send them in email if you like).
An even bigger concern would be that I have machines showing as being patched but that aren’t really because the patch/update reporting isn’t working correctly?
So at the request of support I uninstalled and re-installed the Comodo client agent on the two computers I had that weren’t getting updated patch data (one had been upgraded to Windows 10 and after 3 days was still showing pending Windows 7 patches, even though if I ran windows update manually on the PC, it said everything was up to date).
So here is some more info (I updated the email ticket, but wanted to share on the forums in case others are having the same issue):
Any devices I’ve added to ITSM over the past week or two are all showing “No results found.” in the Patch Management tab in ITSM, both in Operating System or Third Party. I’ve got about 5 recently added devices in total that are all showing that. Older devices still show populated data.
Is there something wrong on the backend with the patch management system? If so, it would explain why it wasn’t updating. Is there a backend service you can restart and see if patch management data starts flowing again?
Sorry guys, I feel like such a complainer in these forums the last few days, but the amount of problems I seem to be having with ServiceDesk reports and now ITSM patch management (that after a lot of troubleshooting do not seem to be on my end) and more recently today with having half of my endpoints (at various customer sites) unable to connect with Comodo Client Viewer (see other post) has me really worried that this is not a stable platform.
Sorry for the delay in response. Yes the issue is resolved as far as it now shows the updates correct. It installed 23 of the 27 needed patches on one and seems to be stuck as it will not install the last four updates. The other machine now shows 6 updates which is correct but it will not install them. I have sent the command several times along with restarting the machine.
We have contacted you via email about this underlying issue that is currently under investigation with our developers. We will update you as soon as we have found the root cause and applicable solution.
I had the same issue with patch status not reporting correctly using PM within ITSM. There seems to be delay in sync with SOME desktops on the patch status or not syncing at all. However just today, the desktop that I had issues with started to report accurately again. I still can’t get my hands on it as to why it’s behaving this way.
Why doesn’t Patch Log show any logs? Am I suppose to see what activities of PM? e.g. submissions, success/fails of PM requests?
I see some issues with the current PM feature:
ITSM PM needs to be able track the patch current status so you don’t send the same PM requests multiple times. E.g. Once an install patch request has been sent, it should update the respective patch with an updated status. Such as “processing”, “failed”, etc. The patch should be grayed out once it’s been requested.
Right now, after I submit an install request, it will continue to show as being “available” and the patch status count stays the same so the you might think install was not accepted by the system.
To make matters worse…
There’s no way of knowing if a desktop is waiting for a reboot. If this doesn’t happen then the rest of the patch request will not install AND there’s no warning from ITSM PM.
After waiting some time not knowing what’s happening, I ended up having to remote into desktop and since you’re already there, you keen to just do all the PM locally.
It’s sort of like a failed loop in the patching process. Anyone share my pain?
We apologize for the issues you’ve encountered. The patch management feature of ITSM uses the Window Update Service in order to install the available Windows Updates. Sometimes there is a delay in the PM information as these files are always syncing.
One of the reasons for the reported issue could be the Windows Update Service itself, so this would be the first thing that needs to be checked. On one of the affected devices, please make sure the service is started and running properly (simply try to install a small Windows update, if it gets installed then the update service is OK).
Hi Riley, still having the same issues as ikondata, it is not Windows Update. My own laptop shows a pending update in ITSM, but when I run Check for Updates, it shows I’m fully up to date. There are definitely syncing problems that persist.
Similarly, I had machines where ITSM just wouldn’t seem to patch them, so, like ikondata, I had to remote in and run Windows update manually. WU had no errors/issues doing the update, it just seems ITSM isn’t telling it to.
In most cases though patch management does work. Of course I’d rather the bugs be where it doesn’t update, and requires manual intervention then appearing as though everything is up to date but it isn’t. I did send some screenshots to support showing some screenshots that seem to show this is indeed happening.