Windows PowerShell: What is Windows PowerShell Workflow?
Using a Windows PowerShell workflow can be a complex process, but ultimately worthwhile in the functionality it provides.
Note: Every month during 2013, Don Jones will present an installment in a 12-part tutorial series on Windows PowerShell Workflow. We encourage you to read through the series in order, beginning with the January 2013 column and proceeding month by month.
Don Jones
The Windows PowerShell Workflow is a new feature in the Windows Management Framework version 3.0. In a broad sense, a workflow is a specialized kind of Windows PowerShell script. It outlines a set of tasks, some of which need to occur in a particular sequence, while others can run in parallel.
Windows PowerShell Workflow comes pre-installed on Windows Server 2012 and Windows 8. It’s also available for Windows 7, Windows Server 2008 and Windows Server 2008 R2. You’ll need one of those OSes to run a workflow. However, a workflow can target—meaning, perform tasks against—any version of Windows, depending on the exact task you’re trying to accomplish.
It’s written using more-or-less standard Windows PowerShell syntax. There are, however, several incompatibilities between workflows and traditional Windows PowerShell scripts. Windows PowerShell Workflow makes heavy use of the Windows PowerShell remoting feature. (Grab my free “Secrets of PowerShell Remoting” guide if you need a remoting primer or configuration advice.)
How workflows work
Looking under the hood (which we’ll do more in-depth later throughout this series), you’ll find a Windows PowerShell workflow isn’t actually executed by Windows PowerShell. Instead, Windows PowerShell translates your script into XAML and hands it off to the WF, which is a portion of the Microsoft .NET Framework. WF accepts the XAML and actually performs the execution.
The fact that WF executes a workflow, and not Windows PowerShell, introduces some interesting capabilities and more than a few complexities. For example, WF is designed to checkpoint the progress of a workflow. That way, if the machine running the workflow is interrupted in some way, such as shutting down, the workflow can pick up where it left off when the machine starts again.
You can also have workflows manually suspended and resumed. For example, you might have a workflow complete a certain set of tasks, up to a point when manual intervention is required. Then you might want it to suspend operation and automatically send an e-mail message with a status update. After completing the manual tasks, you could resume the workflow and let it continue execution.
Workflows can also execute things in parallel, if you like. For example, if you have a set of tasks that can run in any order, with no interdependencies, then you can have them all run at more or less the same time. That shortens the amount of total time it takes to complete the workflow, which improves efficiency. WF also keeps track of each workflow step. This means you can generate a detailed audit log on what tasks have completed, which is a great help with troubleshooting.
Workflows can’t do everything that a Windows PowerShell script could do. As you’ll learn throughout this series, anything you can’t translate into something WF understands is out of bounds. There are definitely a few aspects of Windows PowerShell that won’t transfer. So a workflow is neither a subset of Windows PowerShell nor a superset. It’s a cross-set, meaning workflows add some capabilities to Windows PowerShell, but can also take some away. That’s one of the more complex aspects of workflows.
Not the only answer
A workflow is not the ultimate answer to every task. The excitement around workflows stems from the product team at Microsoft and numerous independent enthusiasts who can give the impression that you should do everything as a workflow. Resist that urge, because workflows have a distinctly higher learning curve. They’re also harder to troubleshoot and debug, and aren’t always necessary.
For example, if you simply need to have a task run against a set of computers in parallel, plain-old remoting can achieve that for you. You could also use a Windows PowerShell version 2-style background job (which still exists in version 3).
If you just need to run a sequence of tasks that restarts the target computer, and wait for it to resume before continuing the script, you can do that with the new version 3 Restart-Computer command (which features a -Wait switch). So while you can see workflows are indeed powerful and have some unique capabilities, they aren’t necessarily the easiest way to achieve every possible task.
The anatomy of a workflow
A workflow, like a function or cmdlet, is a type of Windows PowerShell command. Once you’ve created one, you basically just run it like any other command. You could also schedule it, or push it to a remote machine to run there. At execution time, Windows PowerShell translates it to WF and asks WF to actually run the workflow.
Like other types of commands, you can give workflows parameters that let you customize their behavior at runtime. There are a variety of common parameters available to automatically enable specific behaviors.
You define a set of activities within a workflow. You can set up these activities to run in a specific sequence or in parallel with each other. You can mix and match sequences and parallelized blocks as much as needed. The trick is that each activity must be something WF understands. This is truly where the complexity begins.
The Windows PowerShell team provided WF “versions” of most of the major Windows PowerShell core cmdlets. This means you can use those cmdlets right within a workflow. When translated to WF, those cmdlets are substituted with their WF equivalents, so they’ll run as expected.
In an ideal world, every Windows PowerShell cmdlet would come with a WF equivalent. This would make workflows look a lot like the familiar Windows PowerShell scripts we’ve been writing for years. However, we don’t live in a perfect world. In reality, most cmdlets don’t come with WF equivalents. This is especially true with the cmdlets that come with Exchange Server, SharePoint and Windows Server 2012 (with the exception of core Windows PowerShell cmdlets).
WF can’t natively run these cmdlets. You have to wrap them within something WF understands: an InlineScript. This special activity essentially tells WF to just run Windows PowerShell. It feeds the content of the InlineScript activity to the shell.
Each InlineScript is an independent, standalone and disconnected entity. InlineScripts can’t share information with one another except by persisting the data someplace (such as in a database) they can all access.
These make writing workflows much more complex. However, they’re going to be your main unit of execution for the time being, because most Windows PowerShell cmdlets don’t yet have WF versions.
Here’s what’s ahead
Workflows are definitely exciting. When used for the right task, they provide incredible functionality. They are indeed complex. You’ll have to invest some time learning how to use them. The goal in 2013 is to present a major chunk of information each month:
- February 2013: Cover the workflow environment, including prerequisites and remoting configuration.
- March 2013: Give you a basic workflow example, so we have something to talk about and build upon going forward.
- April 2013: Compare and contrast scripts and workflows, with a comprehensive list of what will—and won’t—work in each.
- May 2013: Dig into workflow activities, including the all-important InlineScript activity.
- June 2013: Look at the common parameters and runtime variables of workflows, and how to use them in your own workflows.
- July 2013: Learn how to add your own parameters to a workflow.
- August 2013: Construct both sequenced and parallelized activities within a workflow, and I’ll show you how to mix and match them.
- September 2013: Look at how to checkpoint workflow progress, and how to manually and programmatically suspend and resume workflows.
- October 2013: Take everything you’ve learned so far and create a new, full-scale workflow example.
- November 2013: Put some perspective into the conversation by showing some of the alternatives to workflows for specific tasks such as parallelizing tasks.
- December 2013: Look at the other ways you can use and interact with the workflow feature set.
I’m looking forward to this yearlong tour of Windows PowerShell Workflow. I hope you’ll join me every step of the way.
.jpg "Don Jones")
Don Jones is a Windows PowerShell MVP Award recipient, and a contributing editor to TechNet Magazine. He has co-authored four books about Windows PowerShell version 3, including free ones on creating HTML reports in Windows PowerShell and Windows PowerShell Remoting. Find them all at PowerShellBooks.com, or you can ask Jones questions in the discussion forums at PowerShell.org.