This video features a PowerShell 3 workflow overview and tutorial from Bruce Payette. Bruce is the Principal Developer in Windows Manageability for Microsoft. This means that he is the main developer for PowerShell 3.0 and is one of the highest authorities on Windows management and scripting with PowerShell.
PowerShell 3 WorkFlow Tutorial
If you’ve heard that Power Shell 3 uses workflows, but you haven’t yet had an opportunity to learn about what it is and how to use it, this video is going to be time well spent.
It’s a ton on information packed into a 45 minute session from the PowerShell Deep Dive 2011 in Frankfurt.
Start the video when you’re ready to begin. And if you just want the highlights then keep reading because I hit the key points for you.
What is Workflow and When Will You Use It?
Workflow is not another way to script, instead it’s orchestration of large, long-running scripts. As Bruce puts it, workflow is intended for “reliably executing long running tasks.”
Workflows take advantage of state persistence: everything in a workflow state can be saved to disk. The example given is a long running task finished processing one part of the script, and then human intervention is required. Once the human intervention is completed, the workflow can be resumed. If a system failure occurs on the machine running the workflow, it’s not going to affect the workflow. You can pick up and resume the workflow process on a different machine and it picks up right where it left off.
The main differences you’ll encounter when working with PowerShell workflows are:
• In a workflow, individual activities are isolated. This is different than a typical power shell session or script where all of the activities take place more or less sequentially and all share the same environment and state.
• Workflows include persistence, so that they are more robust. This allows workflows to stop, pause, restart and recover. Typical PowerShell scripting doesn’t include these state persistent features.
• Data flows through very specific channels when running through a workflow. Everything is very well defined with data that comes in and data that goes out of each part of the workflow. By contrast, scripts are allowed more flexibility with moving data from one part to another, and there can be “implicit” coupling of data.
• Workflows are precise in how the language is typed. A workflow is strongly typed, early bound, and is a compiled language. Scripts can be more loose and forgiving with how the language is typed.
In short – workflows are planned, and scripts are ad hoc.
Overview of the PowerShell Workflow Architecture
There is a PowerShell Workflow Service (not a real windows service, unless you create a service to run the workflow). The PowerShell workflow service is run on a computer which is actually running the workflow. The client is the computer that is initiating the workflow. The client and workflow service computers are usually the same computer, but could technically be two different computers. Finally, the management nodes are the individual management items being processed by the workflow. This could be as many computers as is required, and connections can be made through filesystems, WMI, and many other methods.
Example of a workflow code
Bruce showed this example of workflow code that checks for a required version of a system BIOS that will run on multiple machines. It uses very little new programming syntax changes. I typed in the code so that you can view it and copy paste it for your own education.
workflow Test-MachineBios
{
param ([parameter(mandatory=$true)][string]$RequiredBiosVersion )
parallel {
$workflow:bios = Get-CimInstance -ClassName Win32_Bios |
Foreach -MemberName Version
sequence {
$os = Get-CimInstance -Classname Win32_ComputerSystem
if ($os.Manufacturer -match “dell”) | { $workflow:RebootNeeded = $false }
}
}
inlinescript {
$bstr = “$bios”
$len = $bstr.Length + 15
“*” * $len + “`nBIOS version is $bstr`n” + “*” * $len | Write-Output
}
if ($bios -notmatch $RequiredBiosVersion) {
“Update Required”
if ($workflow:rebootNeeded -eq $true) {
“Reboot needed”
Restart-Computer -wait -for PowerShell -force
}
else {
“Reboot not needed”
}
}
else {
“BIOS is up to date”
}
}
Notes about the code:
- If you want to create a workflow you start it with the workflow keyword. Once used, it enables some other new keywords.
In a workflow, you can use parallel keyword to define tasks that run in isolation but at the same time. That is to say, each statement inside the parallel block runs on its own and at the same time on each system. - If you want to be sure to run one command first, and then another command after, you will want to use the sequence keyword. So even if you’re in a parallel block, the sequence block identifies a group of command that will be run one first, then the next; and that whole group of items being run in sequence will be processed in parallel with any other statements in the parallel group.
- $workflow:bios shows a subset of the PowerShell language that only works in workflows. The data language makes it so you can only perform operations that make sense when working with data. Bruce puts it like this: “It prevents you from doing things that would prevent workflows from having the ability to persist.”
- Since the things you can do in the data language is more restricted, you can use the inlinescript keyword to set aside a scriptblock that has the full PowerShell language available to it. Everything in the inlinescript block processes as one line in the workflow.
Other notes about this workflow, and designing and running workflows:
- If you restart your own computer, the workflow is saved by creating a checkpoint. After the computer restarts, you can resume the workflow.
- As each step of the workflow is processed, progress bars are displayed by default throughout.
- Commands now have a property called “capability” which identifies what type of command it is. Workflows are identified with the capability “workflow”.
- Workflow commands are actually acting as proxies to the Microsoft Workflow version 4 engine.
- The PowerShell text you enter into the PowerShell script is converted into XAML to be consumed by the the workflow engine.
- It’s possible to edit the XAML directly, but not necessary and not recommended.
- If you want to edit the XAML, using the workflow editor from Visual Studio is a good option.
- You can do some basic debugging of workflows with Windows Tracing and Event logs.
- Take advantage of tracing by loading the PSDiagnostics module, then running the Enable-PSWSManCombinedTrace command.
- The Register-PSSessionConfiguration cmdlet can be used to help enable “second hop” connections by configuring remote endpoints to always be run as a specific user.
I can say that after watching this PowerShell tutorial I’m ready to start playing with workflows in PowerShell version 3. I immediately started downloading and installing Visual Studio 2012 so I can get my hands on a decent workflow editor.
Do you know somebody that wants to learn one of the hottest new techniques for working with PowerShell? Be sure to tell the people that need to know that you’ve got a really fast way to get them familiar with PowerShell workflows.
