Kaseya Community

Custom Reboot Action

  • We are trying to implement a custom reboot action so that the user receives a reboot nag every hour until 4 hours has elapsed, after which it will warn the user and reboot in 5 minutes. The way we had originally tried to implement this was set the reboot action to “Do not reboot” and set a sequence of nag procedures to start running as a post procedure.

    The first nag procedure, the one set to run automatically post-update, checked if the user was logged in. If the user was logged in, it would execute nag procedure 2, otherwise it would go to else and run the “reboot” procedure. In nag procedure 2, it asks the user to reboot, and if they choose not to, the else statement will execute nag procedure 3 in 60 minutes. This repeats until the final “no” button is clicked by the user, after which the “reboot with 5 minute warning” is scheduled to run 60 minutes from there.

    Unfortunately we didn’t realize at the time that the “Reboot” procedure would not communicate to Patch Automatic Update that a reboot had been performed. We also had a couple of users stating that their computer would reboot every time they logged in to their account. Looking at their agent procedure status, I see a separate “Patch Reboot Nag” running on their computer so it’s possible that when the “Do not reboot” setting was saved to the policy it wasn’t applied to endpoints.

    Can anyone maybe shed some light on the issues we were having, and maybe give an idea of how to set up a custom reboot action like that (if at all possible)?



  • ,

    This article describes the need for a post-reboot scan to run in order to recognize the manual reboot:  kaseya.zendesk.com/.../33901207.  In this case you're rebooting by procedure, but it's functionally the same as a manual reboot.  You'll need to run a post-reboot scan to complete the patch cycle.

    Regarding the machines running the system Patch Reboot Nag scripts (vs your custom one), check the endpoint to see which Patch > Reboot Action is actually configured.  It's possible the reboot action is not set to Do Not Reboot.  It's also possible that a prior patch cycle had not completed (a cycle started BEFORE you changed the reboot action) and was running nags from that previous cycle.  Once any in-process cycles complete, the next cycle will use your newly-defined reboot action/post-procedure.  The Config Changes and Agent Procedure logs can help determine if a prior cycle was still in process that cause the patch reboot nag scripts to fire.  However, you should first verify that the machines where the users are reporting the system nag are actually configured to your preferred reboot action and post-procedure.  If not, update them appropriately. If you're using Policy Management to define these tasks, be sure to update and apply the policies.

    If you're unsure whether Policy Mgmt is playing a role, check the Config Changes log for settings applied by "System" and/or check the Policy Management > Machines function, hover over the policy status icon for the endpoint, and review the applied and effective settings for the endpoint.

    If you get stuck, I recommend opening a ticket with support.  They will not necessarily be able to resolve any issues that might exist with your custom agent procedure (though they can generally provide guidance on custom APs), they can help to determine why the system patch nag is firing for some machines.

    [edited by: Brande Schweitzer at 10:32 PM (GMT -8) on Feb 15, 2016]
  • Procedure Folder Patching.xml

    So you want more customization in Kaseya... >:-/

    The MSP Platform that makes bold claims such as being the ultimate automation platform *cough* KAV *weeze*

    Here's a run down of how we currently implements the patching reboots.

    First off we use policies (kaseya agent policies) in order to keep all the settings and timing straight. Second, nearly everything is done via an agent procedure. Third we reboot weekly. Fourth, there is a limitation to this design. In theory, it is possible to reboot outside of the maintenance period, but the hypothetical is so rare, and I've only seen it once, on a laptop user, that we aren't really concerned by it.

      Set patch management>configure>reboot action to 'do not reboot after update' on all agents

      Schedule patch management>manage machines> Automatic Update on all agents during the weekly maintenance window.

      Set patch management>manage machines>pre/post procedure 'Run X before Automatic Update' and 'Run Y after Automatic Update' to run a pair of agent procedures. X will set a flag in registry that reboots should NOT be performed. Y will set a flag in registry that reboots can be performed.

      Schedule Z Agent procedures that will check the registry at a certain time/times(during maintenance period),  so that if the reg flag suggests that a reboot should be performed, a reboot will be performed, and the reg flag gets changed so a reboot won't occur after the reboot has happened. These reboot checker procedures.

       Schedule Y Procedure 5-15 minutes before the start of the period

      (Optional)  Schedule X Procedure at the very end of the maintenance window  

    Here's what it looks like: (minus the two about chkdsk and ninite)

    I've attached the procedures we use. GL

  • It looks like the machines having trouble were still in the previous patch cycle, which used the same post-patch procedure (which I had edited to include the reboot nags). So those machines were running the built-in reboot nag in addition to the one I had made a procedure for.

    I went ahead and tested the new nag procedure individually and it works fine, then tested the intended patch settings on an individual machine and it had no trouble. In the end I just made a new post-patch procedure to run and assigned it alongside the new reboot action, that way any machines in a previous patch cycle would also be excluded from running the new nag procedure.

    Thanks for the input!

  • Yea, I like your ideas but we've been burned in the past with the whole reboot action thing.

    Thing is, we don't like to rely on the reboot action feature. It is relatively reliable, but for something that needs to be perfect, it isn't quite the right tool. Since we have rather strict maintenance windows, reboots need to occur within certain periods of time, which isn't something Kaseya natively does, so you need something a little custom.

  • ,

    To clarify, Kaseya can perform a reboot action within a specifically-defined window.  If you use the reboot action:  Everyday at <time> or <Day of the week> at <time>, the reboot will occur on the defined day only if a patch cycle has run and no reboot has occurred.  For example, using a reboot action of <Saturday> at 10pm (let's say this is your allowed maintenance/reboot period):

    Patch cycle runs on your defined day of the week (let's say Thursday at 10pm)

    --The install portion of the patch cycle completes late Thursday night or perhaps early Friday morning

    --Patch cycle suspends; other procedures can continue to run against the endpoint

    --Saturday at 10pm finally rolls around

    --KServer determines whether a reboot/patch scan has occurred since the install portion of the cycle completed

      ---If YES:  no action is taken

      ---If NO:  The reboot action fires to reboot the computer, at your defined time

    Now, let's say your patch cycle is instead scheduled for Saturdays at 8pm and does not complete before 10pm:

    --Patch cycle starts

    --Saturday 10pm rolls around; KServer determines the endpoint is still in a patch cycle.  No action is taken.

    --The install portion of the patch cycle continues and finally completes Saturday at 10:15pm

    --The patch cycle suspends; other procedures continue to run against the endpoint

    --NEXT Saturday (at 10pm) the reboot action from the prior week will fire to reboot the endpoint at the defined time

    The key here is to have your install cycle run with enough time allowed for a typical install to complete before the scheduled Reboot Action is supposed to occur.  This way, the entire cycle (including reboot and rescan) can complete without extended delays between the install and the reboot.

    Finally, let's say there's a week where there are no patches to be installed.

    --Patch cycle starts (let's go back to 8pm on Thursdays)

    --KServer determines no patches are needed for the machine; patch cycle is skipped for the week

    --Saturday 10pm rolls around; KServer determines that there have been no patches installed since the previous reboot.  The Saturday 10pm reboot action does NOT fire since there is no need to 'close out' the patch cycle

    If used well, this specific reboot action can ensure your patch reboots only occur within a specific maintenance window.  

    While I understand there may be additional complexities needed to fully meet what you're trying to do, this specific function is native to the system and will trigger a specifically-timed patch reboot.