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?
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.
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.