Kaseya Community

Major issues with Patch Management this month...

  • Since my earlier post is stuck in moderation hell, I thought I'd try again...

    Is anyone else having major issues with patch management this month in particular?  Right now I've got more than 1/3 of my machines showing failed patches.  I've been doing a lot of research on it today and I'm finding that at least for all of the patches that I'm dealing with right now, the patch source is set to LANCache, and when I look in the LANCache the files for the failed patches don't ever appear in the LANCache.

    Doing some further research I've found another commonality in that the failed patches all specify https urls for the download link as opposed to the ones that are working that are all http urls...

  • Yep. Lots of problems here, and yes all with LanCACHE machines. See also thread community.kaseya.com/.../21654.aspx

    The patch downloader tool Kaseya uses is called curl-nossl.exe for a reason. I weonder what happens if you use the SSL version of CURL from curl.haxx.se/download.html

  • Craig, I thought of that... The main issue being the versions of CURL that support SSL are not single executables, but rely on a couple of additional libraries as well.  Plus from what I can tell, their version of curl is custom compiled by Kaseya... specifically to never return anything on the commandline.  Even adding the -v switch to make it verbose does nothing.  I don't know if that would mess up some of the scripts where they use it or not...

  • On another issue re Patch Management, Im starting to get multiple clients complain that their PC's grind to a halt when we're doing patch scans...

    Patch scans have never had an impact on PC performance, so unsure whats going on.

    Anyone else seeing this?

  • There is/was an issue with windows itself doing patch scans on low-memory machines. e.g. win7 on 2Gb RAM.

    Kaseya patch scans are really just windows patch scans - Kaseya just triggers windows update to do a scan and send back the results....so the 'impact' on performance should be the same as if WU is run on the machine interactively.

    Check if patch support.microsoft.com/.../3050265 is applied, as this fixes that particular issue.

  • I think this is the latest version of Windows Update Agent (they have released a new version every month since July): support.microsoft.com/.../3083710

  • I've set the failing machines to "Download from Internet" as the patch source and still have them all fail.

  • According to my support ticket the issue is supposedly fixed now with updates pushed to all kaseya servers
  • Just trying to understand what your last comment means, Jonathan.

    Is it now fixed for your Kaseya servers, for the online Kaseya servers or literally all Kaseya servers all around the world? I think you mean it's fixed for all Kaseya servers now, but that means they can still push updates without the use of the famous Kinstall?

    That would surprise me just a bit, since we and a lot of others think we're managing our own servers.
    Not, that it's a problem that Kaseya is fixing this issue, but it should be communicated to all Kaseya users.

  • - I added more details in my other thread... I"m pretty sure that what they *actually* did was just do a search/replace of https with http in the patch location download file that they push to *all* Kaseya servers every four hours.  

    Which in my mind is not really a *permanent* fix, but it does allow things to work again for now.

  • j the way I understand it, Kaseya curates a manifest that correlates each patch with a download URL.  The Kserver fetches this manifest on a regular basis.  This is core to how the module works.  It is possible that a change to this manifest is the fix that Jonathan's ticket refers to.

    has an explanation under item #4 at the bottom of this thread.


  • , , ,

    Andrew and Jonathan's assessments are correct.  The Patch Location file was updated.  This file is automatically downloaded on a regular basis and new updates are processed by the KServer.  As Andrew mentions, this is core to how the module works.  

    The update to the file will fix the issue indefinitely, so it isn't really considered a work-around.  However, Development is evaluating the appropriate steps to leverage https patch locations since it's quite possible/likely MS may release some patches only to https sites.  MS's behavior is pure conjecture, but a foreseeable possibility.  The immediate issue is fully resolved and the 'future-proofing' is being addressed internally.  I would anticipate either a patch will be released at some point or the change may be rolled into a future release (or possibly both).  Development will make the call on the appropriate method to handle based on the complexity of the change.