In this post I’m going to cover PowerShell Workflows and when to use them. PowerShell workflows give you capabilities scripts can’t but they also bring constraints and nuances. You have to think about your requirements to determine if you really need workflows or if you can use a different approach to achieve the same end result with less fuss.
When do you need workflows?
- Long running tasks and I mean really long running, think closer to hours not minutes.
- Surviving local reboots (expected and unexpected). You can checkpoint at specific locations in the workflow to resume but more detail later in the post.
- Persistence. You can serialise the workflow state to disk and resume it later. For instance if there is a manual step in the workflow you can suspend it, perform the manual step and resume it again.
- Fine grained flow control combining parallel and sequential execution. This one is not that obvious when you look at a workflow script but you can mix and match and nest parallel and sequential activities.
- Workflows are more robust. The engine creates separate runspaces for activities, if an activity crashed it won’t bring down the whole workflow.
There are probably more but these are the ones I ran into.
When don’t you necessarily need them?
There are situations that look like they need workflows but may not necessarily. Using workflows in these cases won’t be wrong, it will work but it might be overkill.
- Scaling out. Running a simple task on multiple remote servers in parallel can be achieved using remoting. There might be a point where workflows will scale better but only if you avoid InLineScript activities.
- Handling reboots. To a certain level DSC can also deal with reboots by configuring ActionAfterReboot and RebootNodeIfNeeded in the LCM config MSDN article.
- Running tasks in parallel on the same machine. For simple scenarios you can use PowerShell jobs to achieve the same result.
How to survive reboots
Surviving reboots seem to creep into workflow discussion a lot so I’ll have a quick look at it.
The simplest scenario, which is not restricted to workflows by the way, is running a workflow or script that is acting on remote machines. In this case you restart the remote machine using the “Restart-Computer -Wait” command or activity for a workflow. You don’t have to do anything extra since the machine running the workflow or script is not restarting and the script or workflow will continue running after the reboot.
If you want to restart the computer running the workflow you have to do a bit more work. This will only work for workflows not scripts. You still use the Restart-Computer activity which will checkpoint the workflow and suspend it before it restarts the machine. When a workflow is suspended it creates a job of type PSWorkflowJob that will survive the reboot. After the machine comes back from a reboot you have to resume the workflow. If you call Get-Job after the reboot you will see your workflow as one of the jobs and then you can call Resume-Job to resume the workflow.
Then you use the normal job related commands to handle the job and see the output using Receive-Job etc.
If you look at this link reboot scenarios are explained in detail and there is also a section that shows how to automate the resumption of workflows.
To survive unexpected reboots you have to checkpoint your workflow using the Checkpoint-Workflow command at logical points in your workflow. Put some thought into where you place the checkpoints to achieve the correct outcome after a reboot.
Note: You cannot checkpoint inside an InLineScript activity since it cannot be serialised.
