Kaseya Community

Reboot time

This question is not answered

Hi,

We just started looking in to Software Management compared to Patch Management and it looks to be a lot better with reporting of installed patches and faster scanning.

However, is there really no way to set a reboot time of patches? This basically makes it really unreliable for automation of maintenance windows.

Even if we set different times for the patching it doesn't make it 100% that those two times won't collide with eachother and for example take both Domain Controllers down at a customer since one server might be slower than the other. Is there any request to implement this? Seems like a really basic feature to miss.



e
[edited by: Handa at 12:41 PM (GMT -8) on Feb 12, 2018]
All Replies
  • yes, you can go to patch management then click reboot action, that will help determine how the patches are applied.

  • I understand your technical challenge.  What I have in place for specific deployments requiring this is a post update script leveraging the reboot cmd and or reboot procedure with a pause in it.  

  • Even with that it is possible that the servers might reboot at the same time if one server has a lot of updates while one only has a few. Might be unlikely but this seems like such a basic feature for patch management it's astonishing that it is not implemented.

    Just checked R9.5 patchnotes which seems to focus on Software management and it's not in there either. Seems to be focused on patch deployment for client OS and not server OS.



    r
    [edited by: Handa at 12:25 AM (GMT -8) on Feb 15, 2018]
  • We patch servers monthly, and schedule DCs for either opposite ends of a 4-hour cycle or different weeks of the month to avoid that problem. We use policies that schedule a reboot first (to make sure it gets done and updates start clean), then update and reboot if necessary. Haven't had any issues across 400+ servers.

    Glenn

  • Literally the first thing I went looking for was a way to set a reboot action other than "now or never." At this point the option is "interrupt somebody" or "trust them to reboot later" or "schedule an unrelated weekly-reboot script whether there are patches installed or not."

    The other thing which bothers me is there's no way to stagger the scan or install schedules other than making a bunch of different policies and applying them in some weird, probably-manual fashion. If I use Policy Management to deploy this to a client, working-as-intended it's going to start scanning and start deploying all at the exact same time. What happened to distributing the load? Did those programmers who built the 2nd-wave scheduler code fight and die in vain?

    The other other thing which bothers me: There's no option for whether there should be use of the patch cache share or the LAN cache, so I'm assuming everything's downloading from... the KServer? Microsoft? Whoever? What happened to saving bandwidth?

    This feels very Version 1.0 right now and I'm probably going to hold off deploying it to live clients for a while yet. I'm using it internally so we can get some familiarity, but that's it.

  • This sounds familiar - we're using it internally and for a special customer. It's workings are sort of ok-ish, meaning it sort of gets done, what you need, but even so it needs more work for sure...

    As far as I understand all patches get downloaded initially from your VSA. The Endpoint Fabric magically takes care of spreading already downloaded patches to machines in the same subnet (something that was only recently activated in a patch).

  • "What happened to distributing the load? Did those programmers who built the 2nd-wave scheduler code fight and die in vain?"

    It looks like the developers that wrote Software Management started with a clean slate, ignored any pre-existing code base, and never looked at any other Kaseya module.

    Scheduling with 12-hour format? Really? Do I need 16 choices when I enter "1:" to target 1am?

    Weekday/Weekend exclusions that don't actually look at the day of week and prevent one or the other exclusion from working?

    Policies that don't combine like every other policy? And - S-M policies that conflict with other non patching and non S-M policies and corrupt scheduling?

    Scan policies that don't distribute the load?

    We were very enthusiastic about this product and adopted it early on. For the 5 months that we used it, we sent feedback to engineering, opened tickets for bugs, and tried all kinds of possible work-arounds to get things to work. Well, after not getting reliable patches for the past 2 months, we switched back to Patch Management and removed all of the S-M policies last week.

    We had an outage today - VSA saturated our 100M Internet because Software Management didn't stop when the policies were removed. Instead, we found that almost 2700 workstations initiated a Software Management scan at 9:30 am - all at the same time. Apparently no concept of a START TIME and DISTRIBUTION WINDOW. The engineer suggested separate scan schedule profiles for each customer as a work around. While that would work, even they agreed it would not be feasible for more than a couple of customers. 

    I'm very rarely negative about VSA, but this deployment bit us pretty hard, mostly because things that worked throughout the VSA environment functioned differently here, and not for the better. 

    Glenn

  • Amen - you should be a carpenter, you hit the nail right on the head. ;-) We happen to have the same 100 Mbit pipe and that's hardly enough to keep up with Software Management as it is now. And we even got issues with some 300 workstations using it, although recent patches have improved the situation.

    [Sarcasm] Kaseya is like an addict, the gambler that tried to stop gambling customers would be happy with any old promise; they still promise to stop promising things are almost working... [/Sarcasm]

  • OudjesEric - You should see my woodworking shop! :) I get to play with a different sort of router on the weekends!

    Glenn