When should I use PowerShell Workflow?
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Workflow is one of the new heavily advertised features in Windows PowerShell 3.0; it's available on Windows 7, Windows Server 2008, Windows Server 2008 R2, Windows 8 and Windows Server 2012. Despite this, there's a lot of confusion about what it is, what it can do and when you should use it.
A PowerShell workflow is similar to an enhanced PowerShell function. You put commands into it and tell PowerShell to run it. It's "enhanced" in that it supports a few features not found elsewhere in PowerShell, such as the ability to run multiple tasks in parallel, right within the script code. It also lacks a few features found elsewhere in PowerShell, such as support for the Switch construct.
Those additional features come from the fact that a PowerShell workflow isn't actually run inside PowerShell. Instead, it's converted to Windows Workflow Foundation (WWF), a part of the .NET Framework since v3.5, which actually runs the converted code.
And although you're using PowerShell syntax, you have to follow WWF rules, so there’s a steep learning curve. Options such as using variables, what commands you can use and how data passes from command to command all change a bit.
But the learning curve can be worth it. PowerShell workflows get built-in abilities to target multiple remote machines in parallel, provided those machines have PowerShell installed and the Remoting feature is enabled, something that's only a default on Windows Server 2012.
Workflows also have several built-in parameters that can do cool things. Workflows can be interrupted and resumed, accommodating power outages, network hiccups and other temporary failures.
Workflows aren't the only way to achieve these things. It takes little extra work to send a script to multiple remote machines in parallel; the Invoke-Command can do so quite well. By sticking with a "normal" PowerShell script, you avoid the need to learn all of WWF's rules and regulations.
The only thing truly unique to a PowerShell workflow is its ability to interrupt and resume -- and there are some rules and caveats around that ability. In some cases, the way in which you write a workflow in PowerShell may not even permit any interrupt/resume capability.
About the author
Don Jones is a well-known and respected PowerShell expert and educator. He's co-author of three books on PowerShell (see PowerShellBooks.com for a list). You can find his content online, including his PowerShell Q&A forums, by visiting DonJones.com.
Dig Deeper on Windows PowerShell Scripting
Related Q&A from Don Jones
If you don't need a GUI display, PowerShell can be hosted in several hosting applications so you can use cmdlets instead of a graphical input prompt.continue reading
With some simple configuration, admins can run a PowerShell script each time a computer starts with the help of the Task Scheduler GUI and cmdlets.continue reading
Each PowerShell version has different features made useful by add-ins and snap-ins, so admins have to pay attention to what features work where.continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.