Kaseya Community

Procedure with multiple embedded procedures marks Successful even when one step is not run

This question is answered

I've got an odd one here.  I'm pushing 3 out of band Windows patches to our Win7 machines.  To make life a bit easier during the testing phase I created 3 separate Procedures (Step 1, Step 2, Step 3) for the different patches to run in order.  It's a simple procedure, running "executeProcedure" 3 times, once for each of the 3 steps.

Here's where it gets weird, in testing last week I could run the main procedure that runs the 3 procedures back to back, system reboots with no issues.  Now when I run my procedure Steps 1 & 2 complete, Windows automatically reboots and when the computer comes back up Kaseya marks the procedure as Successful.  When I check the Procedure Log I can see that Step 1 & 2 ran, then it skips Step 3 and makes the Procedure complete.

Does anyone have any insight as to why the procedure isn't getting marked as failed since Step 3 never runs?

Verified Answer
  • Trevor,

    Getting sequenced tasks to run with reboots is always tricky. It's one reason we no longer use procedures for this. I actually have an agent redeployment procedure that uninstall the agent & reboots, cleans up the files and registry, reboots, downloads the proper agent, runs the installer with the proper args to complete the process. This is all done via a single script invoked by a single procedure. The script uses the task scheduler to create a task that runs the script with an argument that performs step 2 or 3. The script does the reboot when the task it's controlling is complete.

    Procedure deploys and then executes script without an argument.

    Script creates scheduled task to run "Script --Step-2" - either in an appropriate amount of time or as an "at startup" task. It then performs "step-1" tasks. Reboot when complete.

    Script runs after startup, creates a scheduled task to run "Script --Step-3", then performs the "step-2" tasks. Reboot.

    Script again runs after reboot, performs "step-3" tasks.

    Each task writes to a common or separate log file, as needed. VSA can check for the presence of the log files and pull them back. In this case, I'd use a log file AND a status file - the status file is simply "Step-#.txt" and contains "PASS" or "FAIL" to allow VSA to easily parse the result of each step.

    This "offline" method has saved countless hours of fretting with procedure-based complex commands.

    Glenn

All Replies
  • Trevor,

    Getting sequenced tasks to run with reboots is always tricky. It's one reason we no longer use procedures for this. I actually have an agent redeployment procedure that uninstall the agent & reboots, cleans up the files and registry, reboots, downloads the proper agent, runs the installer with the proper args to complete the process. This is all done via a single script invoked by a single procedure. The script uses the task scheduler to create a task that runs the script with an argument that performs step 2 or 3. The script does the reboot when the task it's controlling is complete.

    Procedure deploys and then executes script without an argument.

    Script creates scheduled task to run "Script --Step-2" - either in an appropriate amount of time or as an "at startup" task. It then performs "step-1" tasks. Reboot when complete.

    Script runs after startup, creates a scheduled task to run "Script --Step-3", then performs the "step-2" tasks. Reboot.

    Script again runs after reboot, performs "step-3" tasks.

    Each task writes to a common or separate log file, as needed. VSA can check for the presence of the log files and pull them back. In this case, I'd use a log file AND a status file - the status file is simply "Step-#.txt" and contains "PASS" or "FAIL" to allow VSA to easily parse the result of each step.

    This "offline" method has saved countless hours of fretting with procedure-based complex commands.

    Glenn

  • gbarnas Thanks for the tip!  I just changed the 3rd step from execute to schedule and put in a short 2 minute delay since it was rebooting between step 2 and 3.  Once I had that in place the 3rd patch went in with no issue after the reboot.