PowerShell Workflow for Mere Mortals: Part 1

Doctor Scripto

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 node) runs at least Windows PowerShell 2.0. I do not need Windows PowerShell 2.0 if the workflow does not run Windows PowerShell cmdlets. I can use WMI or CIM commands on computers that do not have Windows PowerShell installed. This means that I can use Windows PowerShell workflow in a heterogeneous environment.

The computer that runs the workflow is the host (client) computer. It must be running at least Windows PowerShell 3.0 and have Windows PowerShell remoting enabled. In addition, the target (managed node) computer must have at least Windows PowerShell 2.0 with Windows PowerShell remoting enabled if the workflow includes Windows PowerShell cmdlets.

A simple workflow

Although much of the focus with Windows PowerShell Workflow is about large network management, I can use Windows PowerShell Workflow on my own local computer. I might want to do this if the task at hand might take a long time to run. Therefore, from a learning standpoint, it makes sense to begin with a workflow that simply works on my local computer.

To write a workflow, I begin with the Workflow keyword. I provide a name for the workflow, and inside the braces (script block), I specify the script that I want to use. The syntax is very much like a Windows PowerShell function. Here is my basic workflow:

Workflow HelloUser

{ “Hello $env:USERNAME” }

Just like a Windows PowerShell function, I need to run the script and load the workflow prior to using it. In the Windows PowerShell ISE, I run the script that contains the workflow, and then I can use the workflow in the immediate window. This is shown in the following image:

I can use normal Windows PowerShell commands and add logic to my workflow. The following workflow uses the Get-Date cmdlet to retrieve the time in 24-hour format. Then if the hour is less than 12, it displays “good morning.” If the hour is between 12 and 18, it displays “good afternoon.” Otherwise, it displays “good evening.” Here is the workflow:

Workflow HelloUserTime

{

 $dateHour = Get-date -UFormat ‘%H’

 if($dateHour -le 12) {“good morning”}

 ELSeIF ($dateHour -gt 12 -AND $dateHour -le 18) {“good afternoon”}

 ELSE {“good evening”}

}

MD, there is a start for using Windows PowerShell Workflow. Windows PowerShell Workflow for Mere Mortals Week will continue tomorrow.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy 

Doctor Scripto Scripter, PowerShell, vbScript, BAT, CMD

Follow