Manage Learn to apply best practices and optimize your operations.

When to use a PowerShell workflow

A PowerShell workflow may be one of the most talked about features in PowerShell v3, but that doesn't mean admins know how to use it.

When should I use PowerShell Workflow?

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 administration tools

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.