PowerShell Workflow for Mere Mortals: Part 1

Summary : Microsoft Scripting Guy, Ed Wilson, begins a five-part series about Windows PowerShell Workflow.
Hey, Scripting Guy! What is up with Windows PowerShell Workflow? Everyone acts like it is some deep, dark mystery—similar to trying to understand neutrinos . So come on…it is Windows PowerShell, so how hard can it be?
—MD
Hello MD,
Microsoft Scripting Guy, Ed Wilson, is here. This week I am going to address some questions and comments that have been collecting about Windows PowerShell Workflow. I like using Windows PowerShell Workflow because it offers a number of significant capabilities that help solve rather interesting issues.
Note This is the first in a five-part series of blog posts about Windows PowerShell Workflow for “mere mortals.” For more information, see these Hey, Scripting Guy! posts about Windows PowerShell Workflow . For a conceptual introduction, see When Windows PowerShell Met Workflow .
Why use workflows
Windows PowerShell Workflows are cool because the commands consist of a sequence of related activities. I can use a workflow to run commands that take an extended period of time. By using a workflow, my commands can survive reboots, disconnected sessions. They can even be suspended and resumed without losing the data. This is because the workflow automatically saves state and data at the beginning and at the end of the workflow. In addition, it can use specific points that I specify. These persistence points are like checkpoints or snapshots of the activity. If a failure occurs that is unrecoverable, I can use the persisted data points, and then resume from the last data point instead of having to begin the entire process anew.
Note Windows PowerShell Workflow is Windows Workflow Foundation. But instead of having to write the workflow in XAML, I can write the workflow by using Windows PowerShell syntax. I can also package the workflow in a Windows PowerShell module. For detailed documentation, see Windows Workflow Foundation .
The two main reasons to use Windows PowerShell Workflow are reliability and performance when performing large scale or long-running commands. These reasons break down into the following key points:

Parallel task execution
Workflow throttling
Connection throttling
Connection pooling
Integration with disconnection sessions

Workflow requirements
I can run a workflow that uses Windows PowerShell cmdlets if the target (the managed...(read more)