PowerShell Workflow Controller

PowerShell Workflow Controller

PowerShell Workflows have very specific use and I have only came across a few people using them. Still, I have found them quite useful to resolve a few scenarios where I could use no other technology to solve the problematic. In this post I’m not going to cover all I’d like to cover on workflows (I’ll leave that for another post, someday…), instead I’ll share with you a specific scenario, how to resume a workflow running locally that required the machine where it is running to be rebooted.

So, in summary, these are the main scenarios where you’ll find PowerShell Workflows to be handy:

  1. Run parallel activities in multiple remote computers.
  2. Run remote activities that require the remote system to be rebooted, and resume the execution of the activity after the reboot.
  3. Run local activities that require the system to be rebooted, and resume the execution of the activity after the reboot.

Scenarios 1 and 2 shouldn’t present any challenges and you might even find alternatives to workflows to address your needs. But scenario number 3 it’s quite interesting.

PowerShell workflows, allow you to execute a workflow, reboot the computer as part of the execution and continue executing the script when the system is back online right where the script was left before rebooting. Try the following:

After the reboot, you can check what files are there, and resume the execution of the workflow (using Resume-Job, as the PowerShell Workflows Engine relays on the PowerShell Job Engine for managing jobs):

Now, executing workflows which require the system on which the workflow is running to be rebooted presents a challenge, and it summarizes to: a workflow, can only be resumed from the same execution context that it has been started from. What do I mean by execution context? I have named execution context to a combination of the following:

  • Who did execute the workflow (User)
  • Session type under which the workflow was started (Interactive, Service, Batch job, etc.)
  • Privilege elevation level

In fact, you can do the test, consider the previous script, after rebooting the system, open 2 PowerShell windows, one with the same user you executed the script / workflow originally, and another one under a different user. If you run Get-Job command let, you’ll see that the job to be resumed is present in one Powershell session, but not in the other one.

In the example script, that was not a concern, we logged in as a specific user, we ran a workflow, the system rebooted, so we logged back in, and resumed the execution. This is not always possible, think about automation, might be you start a workflow under an execution context that is never available again (or at least, not when we need it). The solution I have found is to execute my workflows under the execution context that is always available, in other words, SYSTEM.

To be able to do such a thing, I have written a controller script (Invoke-WorkflowController), which you can find in GitHub: https://github.com/hjlarrea/PSWorkflowController. In essence, the script relays on the Schedule Jobs engine of the operating system. It supports 5 main operations:

  1. Start a workflow under the SYSTEM context: pretty much self explanatory.
  2. Schedule a workflow resume: before invoking the reboot activity, use this option of the workflow controller to instruct the Windows Scheduler to resume your workflow.
  3. Resume a workflow after a reboot: this is an internal feature that is executed by the scheduled task created under step 2.
  4. Schedule a workflow cleanup: in order to do some housekeeping, once your workflow finishes it should delete any scheduled tasks and Powershell jobs left behind.
  5. Execute cleanup: similar to step 3, this is an internal operation that is invoked by the scheduled task created in step 4.

You’ll find all the documentation relevant to the script on the GitHub repository. Still if you have a doubt, a comment, or a suggestion, feel free to reach out. And if you did find this useful, don’t for get to leave a comment!

Hernán J. Larrea

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.