Kaseya Community

Patch Scan/Pending Patch Issues

  • Hello,

    We have approved patches for a test group and Automatic update runs correctly.  Patches are installed (according to Windows on the endpoints) but all installed patches are still showing as 'Pending' in Patch Status.  Subsequent patch scans do not resolve the issue and endpoints are rebooting or bugging users every day.  Has anyone else seen this particular issue this month?  We are on 9.2.

  • ,

    The patch process isn't closing out - the patches might have executed on the endpoint and successfully installed, but that doesn't close out the patch cycle.  The patch cycle is described here:  kaseya.zendesk.com/.../36047467

    Until that cycle closes out, the Pending flag will remain.  This could be as simple as a needed reboot, but may be related to a file source being unavailable or some other Agent Procedure managing to run in-between the string of patch scripts and that AP is putting the patch cycles on hold (or several other variables).  The Agent Procedure log and/or Configuration Changes log should be able to help identify where the agent is in the cycle so you can track back what may be preventing its completion.

    If you're unable to determine the cause, please open a ticket at helpdesk.kaseya.com.  Our support team will work with you to review your system and determine the cause.

  • Thanks Brande.  We did open a case with the helpdesk.  As far as we can tell, everything in the logs indicates normal behavior.  Machines are updating, rebooting and scanning as normal.  We'll see what they find.

  • we also see the 'issue' where the patch process seems to not complete for a long time in the VSA.

    The patch cycle seems to run on schedule, agents get the patches applied in good time and reboot, all the pending scripts complete etc. however the VSA still shows the patches as pending, several hours later (all patch activity having successfully completed on the agent, all reboots completed, WU on the agent showing patches installed successfully, etc.). Eventually if we wait long enough (typically the next day, by which time the next scheduled automatic patch scan, which we run once every 24 hours, has completed), the VSA will eventually 'catch up' and display the correct status.

    We too have extensively checked logs and so on, and found no errors or reasons why this may happen. We feel it will be fruitless to open a support case as there isn't any "error" as such, more a "latency" in the VSA UI showing the updated patch status. The level 1 support people who handle the tickets, frankly, aren't able to understand that we are reporting genuine bugs, and instead only want to do basic first level troubleshooting, such as asking us to try a different browser, or saying "it looks OK now" when they finally respond to the support ticket a week later.

    This is something that changed/broke in R9.2 - everything was fine in 9.1.

    it wold be useful to have a separate support queue for your trusted beta testers to submit genuine bugs, as opposed to run-of-the-mill support requests. That way we can be taken seriously and get straight to someone who looks at the problem from the point of view of fixing bugs, and not treating it as a user-needs-help type support request.

  • ,

    I encourage you (and anyone else experiencing this issue) to open a ticket.  It may be difficult to pinpoint the issue, and it might be an issue that support can't immediately identify or resolve, but having the behavior reported builds a framework for a pattern of the behavior.  For issues that are really hiding under rocks in the code, having multiple reports of the behavior - as many as possible - makes a massive difference in the issue being treated as an anomaly on one or two systems to being recognized as a widespread problem.  Tickets truly is how these kinds of issues get resolved because having a wide variety of unexpected behavior across several environments helps to focus the investigation into the common areas of overlap.  

    As far as this issue specifically - after a patch reboot, a patch rescan should run automatically.  These are generally scheduled to run at some point in the future (~10 minutes).  There should be an entry to this effect in the Agent Procedure log.  Support can look into whether the script is being scheduled, whether it's scheduled but not running, if it's running but not returning data, returning data but not consuming, etc.  If the script SHOULD be scheduled but isn't getting scheduled, this wouldn't necessarily lead to an AP log entry error, but there may be indication elsewhere.  At a minimum, it should be fairly easy to check for the presence of the scheduled script at the expected time.  

    With regard to your suggestion, I will pass that along.  You might also consider a KCA as this is a specific, recognized level of knowledge of the VSA system that Support considers in ticket handling.  Information regarding KCA benefits is available in the Kaseya Support Policy.

  • I have opened a ticket and Support was able to identify what seems to be some issue with the messaging system.  Restarting the Kaseya Messaging service did help with a few endpoints, but there are still several more that are experiencing the issue.  Patch Scans are not the issue here, they are running fine and without issue.  Nothing is wrong with the patching process that we can tell, it's getting the VSA to display accurate results of those patch scans that is the issue.

  • the term KCA does not appear in the document you linked to. Not exactly helpful to use an acronym that isn't explained or defined in the materials you're referencing.

    Perhaps you meant "Kaseya Certified Administrator" ? The link to that term on page 4 of that document points to www.kaseya.com/.../certification which returns a 404 error.

    More bugs ;)