Stopping an action on a single machine

(imported topic written by snoczp91)

If you deploy an action group (of MS patches in this case - as a baseline) and afterwards a user goes DOH!, I can’t reboot for several days due to a test I am running, is there a way to stop the action in the single machine without stopping the entire action on all machines?

Hope this makes sense.

Thanks,

(imported comment written by BenKus)

Hey snoczp,

This request is what we consider “editing an action” and we see all sorts of problems with that approach and it is not allowed in the current system… Sorry… You should stop and then re-take the action.

Ben

(imported comment written by SystemAdmin)

Is this still the case? Is it not possible to stop an action for a single computer?? I have had several instances, and can forsee always needing the ability to stop an action for a single computer. Is it not possible to just “remove” the computer from the action? Having to stop and re-take an action is a very big problem when a big software package (such as office 2010) is involved. If the package has downloaded but pending user install and you stop and re-start the action will it not require the package to be re-downloaded??

(imported comment written by snoczp91)

It would be a great future feature if there was a way from the console to stop an action on a single/specific computer. I would not want to give the end user the option, but for a Master Operator, or console operator, it would be a great feature.

Thanks.

1 Like

Still no option to do this? in 2018??? Very inconvenient and inefficient when I have to stop and action going to 1,000 users when just one is having a problem with it. The only other option I’ve tried is to lock the computer having the issue until the rest of computers finish the action. Then I unlock the troubled computer and deal with it individually.

We haven’t fully implemented this, but our current plan:

Have a file on the system in a specific directory ("/temp/donottouchthissystem.bigfix"). If that file exists then we don’t take action. Requires it to be part of the relevance of the fixlet/action, but it is a small price to pay for the ability to stop actions from the system rather than from the console.

We’ve ran into this issue also. I’ve found that if you allow your users to postpone the reboot for a period of time you can use the bes client restart fixlet to reset the timer. So if we gave our users 4 hours to reboot but a user calls and says they need 8 hours before they are able to reboot we just schedule the bes client restart action before the time expires…then they get another 4 hours. The only issue is that they get the action message again, which they can postpone.