Hi all,

I have a patching schedule set up to run every Wednesday between 11AM and 1PM. The patching schedule is set to prompt the user before rebooting, with a timeout of 30 minutes, a timeout action of Reboot Later, and a reprompt interval of 360 minutes. Further, it is set to suspend pending tasks after 120 minutes from scheduled start.

I have noticed that the suspend portion of this doesn't work as I would expect. If the user gets a prompt to reboot their computer, it will continue prompting them until a reboot, and after that reboot will continue with the patching job until I manually cancel it by forcing the task to time out or until all patches are applied. I would expect it to stop asking them to reboot and quit applying patches after 120 minutes (as it does if the user never gets a prompt about rebooting).

Has anyone else had this issue before? I am using server version 5.3
0 Comments   [ - ] Hide Comments


Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
Answer this question or Comment on this question for clarity


Here is a stab at what may be happening. Maybe the suspend time is the total time the kbox spends on a job. So let's say your computer starts a detect and deploy job at 11:00am spends an hour installing patches then prompts for a reboot. The kbox clock for this job is stopped and waits for the user to reboot. So total time spent is an hour. After the reboot occurs the kbox will continue with the job at the 1 hour mark and will run for a maximum of another hour then stop the patching process once it reaches a total time spent of 2 hours.

Now this is just a hypothesis on what the kbox maybe doing, but it would be nice to give it a hard stop time of don't do anything else at x time or something to that effect.

In my environment I haven't noticed this issue on 5.2 but we just started using the patching module, and our patching jobs usually occur at night.
Answered 08/31/2011 by: darkhawktman
Green Belt

Please log in to comment
Ahh, yes, good thinking. That would make sense because some of our users don't reboot even after seeing the message 3 or 4 times so the timer never moves on. Perhaps I can make a smart label that only contains the machines between 11 and 1, but even if that works it carries some other problems...

Thanks for the input.
Answered 09/01/2011 by: cleitch
Senior Yellow Belt

Please log in to comment
A pending task is a task that has not started yet. If a patching schedule is set to run from 11a-1p but a specific machine starts their task at 12:59p then that task will continue to run. I don't know how the snooze features affect a task as pending or not. Take a look at the task itself to monitor it (settings->support->ts tool-> agent tasks -> search by machine you're working with).
Answered 09/06/2011 by: GillySpy
Seventh Degree Black Belt

Please log in to comment
None of your explainations make sense to me. Why would it be labeled "Suspend pending tasks after ____ minutes from scheduled start" if it doesn't mean just that? If the scheduled start is 11 AM, and I tell it to suspend 120 minutes later, it should suspend at 1PM. Period. If that is not what it means, then KACE should re-word the control label to clarify what that actually does.
Answered 09/07/2011 by: zookdj
Second Degree Blue Belt

Please log in to comment
In the example: There is a patch schedule set to run against x machines within the window of 11a-1p. The window is defined for patch tasks starting at 11a with no pending tasks started after 1p. In reality the kbox is going to run y tasks. y<=x depending upon how much work can be started between 11a-1p. A task that hasn't started yet is "pending". Any task that starts between 11a-1p (including 12:59p) is no longer pending and will not be suspended. Any task that is still pending will be suspended.

It should also be noted that it's possible that y=0. For example, if your kbox was already busy working through (a queue of) other tasks and none of the pending patching tasks were started during that time.

When you set a patch schedule to start at 11a you are saying "with respect to all tasks of all types and priorities on the kbox: add patching tasks to the list of pending tasks starting at 11am. Use your algorithm to calculate which tasks should run first on which machines. Any patching tasks you cannot start before the deadline please suspend them"

The things that will most affect y are:
  • what else is your kbox doing?
  • how many machines are requested to be patched?
  • how long does each task take? (this a cumulation of network speed, PC speed, quantity of patches, kbox processing speed, etc)
  • what is the task throughput (concurrent task governor) of the kbox?

If y is often less than x then consider each of these variables with the goal of getting y=x.
Answered 09/07/2011 by: GillySpy
Seventh Degree Black Belt

Please log in to comment