Kaseya Community

Patching with Kaseya MUCH Slower than Windows Updates

This question is not answered

Hi There!

We have really struggled with patch Management. One of the things that drives us crazy, is that to install 151 patches on a brand new i7 PC with Kaseya will take nearly 3 hours. The same thing initiated from the PC with it downloading patches and restarting JUST twice, takes 24 minutes. Kaseya support tell me that's normal, but I don't think it should be normal. 

I understand that for many 3 hours isn't that big of a problem since they patch overnight, but we patch machines we sell and they might be on a tight deadline for delivery. 3 hours for patching doesn't seem reasonable, especially since the patches are coming off our lan at GB speeds as opposed to Windows Updates coming down at the maximum speed of our Internet which is 80Mbps.

All Replies
  • I am sure when Kaseya developed that methodology there were sound reasons for it but no one is stopping you going and finding an alternative.

    [edited by: ghettomaster at 3:43 PM (GMT -8) on Nov 12, 2012] .
  • Agree with ghettomaster.

    networkn, Really if you just have a workstation missing a few patches then you should just let it do automatic updates via Kaseya or schedule an automatic update to run straight away rather than run initital update. I heard a birdie that in VSA 6.3 there will be a "run now" on the automatic update screen which will be the same as an automatic update and should be similar to run windows update.

    If you do schedule kaseya to run automatic update straight away it messes up your schedules so yes it is cumbersome.

    Also as ghettomaster suggested this is really only for one pass and like windows update after the reboot it might still have new patches required for the service pack. Or to patch the patch.

    Initial update is really for a really old un-updated system. For example if you have a Windows XP machine running RTM. It first needs to install SP4, then IE, then any other update and patches, yes even windows update you will need many many reboots to have the system fully up to date. Intitial update is really not designed for a modern day windows 7 system. Intitial update with all the reboots, patch scans etc does take longer but is a sure fire guarnteed way to get that system up to date and not miss patches that have failed to install... How often do you run windows update to find an update failed to install and then when you reboot and run it again it works?

    I have lodged tickets with Kaseya on this and they have advised not to use initial update on my scenario.

  • Which scenario?

  • I heard a birdie that in VSA 6.3 there will be a "run now" on the automatic update screen which will be the same as an automatic update and should be similar to run windows update.  - Birdies lie quite a bit :o)

  • Maybe it could help,

    I do like that my updates :

    Periodicly I powered a blank computer with no update on the network, then affect him the patch source to the server near of him. It take a while to download everything so i plan it on night or on week end to minimize the bandwidth overuse. Then I've got a full folder with all my updates ready to be downloaded. I've notice the fact following, if you plan multiple machines on the same Lan Share, sometimes the Kserver told to the managed workstation to download the patch twice because server don't have the request file, so I do like I explain, just one machine by OS for start then both of them after...

    If you install new machine, why don't you add update in your installation media ? it's should be better to do like that...

  • Ho, i'd forget this, Microsoft updates use BITS to reduce the time to download and install patch on the machine, I'm not sure but maybe Kaseya don't use it ...

  • I had occasion to use the 'initial update' mode of Kaseya today. Patching was horribly slow as we all know; however I noticed something I've missed previously: On the 'initial update' screen, it says the following:

    ["Automatically applies all service packs and patches according to the Patch Approval policy. Service packs and patches are installed in the following order: (1) Windows Installer, (2) OS related service packs, (3) OS update rollups, (4) OS critical updates, (5) OS non-critical updates, (6) OS security updates, (7) Office service packs, (8) Office update rollups, and (9) All remaining Office updates."]

    So, updates are *not* applied in anywhere near the same fashion as with Microsoft WUA (WUA can resolve dependencies and apply multiple classes of patches together at one time without needing reboots in between). Instead, each category of patch is updated separately, with a reboot and patch rescan in between each. This is just horrible, and here's why:

    Doing a patch rescan takes around 5 minutes(but often much longer), which greatly delays the whole process; if I'm reading this correctly there are up to 9 reboots required, meaning 9 x 5 minutes, or at least  an hour wasted just in "overhead" besides actually applying patches. Add to this the fact that there are often patches-to-patches e.g. patch pass 1 installs .net 4.0, reboots, patch rescans, installs security fixes to net 4.0, reboots, patch rescans, installs additional fixes, reboots, patch rescans, etc. etc.

    Horrible. no wonder K is so slow at patching.

    Now, I get that there are dependencies involved here e.g. you know patch 2 is ultimately required, but that the machine first needs patch 1 applied or patch 2 will just fail, but there need to be a little more intelligence brought in here. The current logic probably made a lot of sense 5 years ago, [and I tend to agree that one should always do steps 1 and 2 first], but we have moved on from that; WUA is a lot smarter now.

    I would humbly suggest that the sequence be changed to  (1) Windows Installer, (2) OS related service packs, (3) all other remaining patches, (4) patch rescan and repeat step (3) until all remaining patches either apply (or fail - so as to avoid infinite loop)...This won't make things perfect, but it sure has to help cut down the time wasted doing all those unnecessary reboots and rescans.