Kaseya Community

Better method for installing patches? It really slows their PCs.

  • Ideally I wish Kaseya would give the users the option to defer the installation of the patches for a configurable amount of time but that's not currently a feature.  I swear I put in a feature request but I'm not finding it.

    For my users that don't have SSDs sometimes the install process makes their computers really slow for 3+ hours. 

    My process
    I break the users into two groups (phase 1 (smaller group) and phase 2 (everyone else))
    Once a month I copy phase 1 to phase 2. (just realized this isn't helping)
    Review and approve the new patches in phase 1.
    I have Windows updates scheduled to run bi-weekly after hours spread out by 2 hours.

    The users have been instructed what night the patches are installed but some of them don't remember and some with laptops are offline.  When they come in the next day (if offline) they are bombarded with 30+ patches on some cycles.

    What should I be doing differently?

  • You might consider testing the difference in performance degradation by varying the file source.  Each file source will introduce the installer files to the environment in slightly different ways.  If you're using "From Internet", the install method is the same as if you were to run Windows Update from the local Control Panel.  Using LAN Cache or UNC Path (LAN Share) will copy the files from the internet to the defined server, then from the server to the endpoint.  If the server is not on the same LAN as the endpoint, then you may find copy times significantly increase since the connection pipe isn't usually as hefty when coping from a server off the endpoint's LAN.  Consider spinning up a LAN Cache or LAN Share on the same LAN as each network.  The endpoints on the LAN can all share a single patch file source server, but there's no real benefit to using LAN Cache or LAN Share if the endpoint and the server aren't on the same LAN.

    Via KServer (if you're on premise) is often the slowest option since the KServer is often busy with other tasks - copying files for patches can take time, and the endpoint will sit and wait until the KServer downloads and then hands off the files to the endpoint.  That wait time shouldn't cause performance degradation on the endpoint, but can slow the overall patch cycle.

    Sometimes it just comes down to resources - beefing up the endpoints and/or network connection will often address performance/latency, but of course that requires the budget and time to do so.  Your best bet may be to figure out the specific part of the cycle causing the pain (endpoint itself, connection to the file source, connection to the internet) and try to add some heft there.

    You can also try to script a pre-procedure to run before patch begins to prompt the user whether it's ok to start to patch or if patch should be delayed for a specific period (10 minutes, 1 hour, 1 day - whatever timeframe you decide is ok).  This can be a complex calculation depending on how your update schedule is configured, but it could potentially be done with some trial and error.  

  • And how do you schedule the patch scan? As scanning could affect the users more than the updates itself you need to make sure you plan this accordingly.

    You only need to scan once before running automatic update. A scan will be performed after automatic update.

    (And make sure you update to the latest Windows Update Agent : support.microsoft.com/.../3050265)

  • Having the same issues as - biggest problem we've found are underpowered workstations.  Windows 7/8/8/1 with 2GB of RAM or less stuggle and patch updates can take hours - then we have the dreaded please wait whilst windows installs updates upon reboot.  Unfortunately this is a Microsoft issue and no matter what we do with Kaseya we simply have to apologise to customers and explain this is a necessary evil that we have to put up with.

    We've started making sure that WOL is setup so on some sites we can wake the machines up patch them and  put them back to sleep and this works really well.  Unfortunately we have so many endpoints we're only scratching the surface.

  • you are right, low RAM machines take ages to patch. Sell them more RAM - the few dollars per machine will be well spent in terms of increased user productivity, as well as the bonus of decreased patchtime.

    To all: Much of the extra time lag in K patching, is downloading the patches from the internet - if you set up Kaseya LANCache, this time can be reduced enormously.

  • Apply this update and your 2GB machines will be happy again: support.microsoft.com/.../3050265

    Same problem as I reported regarind out of memory for windows update agent. This will solve a lot of issues with Windows Update Agent and (among many systems) Kaseya Patching.