Getting Started with Windows PowerShell Workflow

Article
08/31/2016

Applies To: Windows Server 2012, Windows Server 2012 R2

IT Pros often automate the management of their multi-device environments by running sequences of long-running tasks, or workflows, that can affect multiple managed computers or devices at the same time. Windows PowerShell Workflow lets IT Pros and developers leverage the benefits of Windows Workflow Foundation with the automation capabilities and ease of Windows PowerShell. Windows PowerShell Workflow functionality was introduced in Windows Server® 2012 and Windows 8, and is part of Windows PowerShell 3.0 and newer releases of Windows PowerShell. Windows PowerShell Workflow helps automate the distribution, orchestration, and completion of multi-device tasks, freeing users and administrators to focus on higher-level tasks.

Windows PowerShell, first introduced with the release of Windows Vista and Windows Server 2008, is a distributed automation engine, command-line shell, and scripting language that is constructed on the Microsoft® .NET Framework. It is designed especially for automating Windows management.

Windows PowerShell Workflow is a key feature of Windows PowerShell 3.0 and Windows PowerShell 4.0. For more information about Windows PowerShell, see What’s New in Windows PowerShell.

This topic includes the following sections.

Overview of Windows PowerShell Workflow

A workflow is a sequence of programmed, connected steps that perform long-running tasks or require the coordination of multiple steps across multiple devices or managed nodes. Windows PowerShell Workflow lets IT pros and developers author sequences of multi-device management activities, or single tasks within a workflow, as workflows. By design, workflows can be long-running, repeatable, frequent, parallelizable, interruptible, stoppable, and restartable. They can be suspended and resumed; they can also continue after an unexpected interruption, such as a network outage or computer restart.

Windows PowerShell workflows can be authored or defined by using Windows PowerShell syntax, or XAML files. For more information about authoring a Windows PowerShell script-based workflow, see Writing a Script Workflow. For more information about XAML-based workflows, see Creating and importing workflows by using the Visual Studio Workflow Designer in this topic.

By using the RunAs functionality of Windows PowerShell, custom session configurations let delegated or subordinate IT Pros run workflows or activities within a workflow.

Activities

An activity is a specific task that you want a workflow to perform. Just as a script is composed of one or more commands, a workflow is composed of one or more activities that are carried out in a sequence. A script can also be used as a single command in another script, and a workflow can be used as an activity within another workflow.

Benefits of Windows PowerShell Workflow

The following list describes many of the benefits of Windows PowerShell Workflow.

Use Windows PowerShell scripting syntax

IT Pros can use Windows PowerShell scripting skills to author script-based workflows by using the extensible Windows PowerShell language. Windows PowerShell script-based workflows are easy to write, and can be shared easily by pasting them into an email, or publishing them on webpages.
Multi-device management

You can simultaneously apply workflow tasks to hundreds of managed nodes. Windows PowerShell Workflow adds common parameters to workflows automatically, such as PSComputerName, to enable multi-device management scenarios. For more information about parameters that are reserved for workflows, see “Reserved Words in Workflows” in Workflow Authoring Reference Topics.
Running a single task to manage complex, end-to-end processes

You can combine related scripts or commands that act on an entire scenario into a single workflow. Status and progress of activities within the workflow are visible at any time.
Automated failure recovery

Workflows survive both planned and unplanned interruptions, such as computer restarts. You can suspend workflow operation, then restart or resume the workflow from the point at which it was suspended. You can author checkpoints as part of your workflow, so that you can resume the workflow from the last persisted task (or checkpoint), instead of restarting the workflow from the beginning.
Connection and activity retries

By using workflow common parameters, workflow users can retry connections to managed nodes if network connection failures occur. Workflow authors can also specify activities that must run again if the activity cannot be completed on one or more managed nodes (for example, if a target computer was offline while the activity was running).
Connect and disconnect

Users can connect and disconnect from the computer that is running the workflow, but the workflow remains running. For example, if you are running the workflow and managing the workflow on two different computers, you can log off of or restart the computer from which you are managing the workflow, and monitor workflow operations from another computer (such as a home computer) without interrupting the workflow.
Task scheduling

Workflow tasks can be scheduled, and started when specific conditions are met, as with any other Windows PowerShell cmdlet or script.

How Windows PowerShell Workflow and Windows PowerShell scripts differ

In a script, the entire script runs in the same runspace, the operating environment that defines which commands, variables, and other elements are available. In a workflow, each activity within the workflow can run in a different runspace. Variables that are created at the top level of the entire workflow are available throughout the workflow; if they are created at the script or command level, they are available for the command or script, but not available to the entire workflow.

In general, you should consider using a workflow instead of a cmdlet or script when you must meet any of the following requirements.

You need to perform a long-running task that combines multiple steps in a sequence.
You need to perform a task that runs on multiple devices.
You need to perform a task that requires checkpointing or persistence.
You need to perform a long-running task that is asynchronous, restartable, parallelizable, or interruptible.
You need to run a task on a large scale, or in high availability environments, potentially requiring throttling and connection pooling.

Creating and importing workflows by using the Visual Studio Workflow Designer

In addition to authoring workflows that use Windows PowerShell scripts, you can author workflows by using the Visual Studio Workflow Designer. Workflows that you author in Visual Studio Workflow Designer have a XAML file name extension. You can invoke and import workflows in Windows PowerShell Workflow that are authored in Workflow Designer, and expose Windows PowerShell cmdlets as activities within the Workflow Designer.

For more information about authoring workflows in the Visual Studio Workflow Designer, see Using the Workflow Designer in the Visual Studio documentation on MSDN.

Windows PowerShell Workflow activities in the Visual Studio Workflow Designer

Windows PowerShell includes built-in activities for most Windows PowerShell cmdlets. These activities are packaged in assemblies with names that match the name of the Windows PowerShell module that contains the cmdlets. The following is the list of Windows PowerShell activity assemblies that are installed in the Global Assembly Cache (GAC).

Microsoft.PowerShell.Activities
Microsoft.PowerShell.Core.Activities
Microsoft.PowerShell.Diagnostics.Activities
Microsoft.PowerShell.Management.Activities
Microsoft.PowerShell.Security.Activities
Microsoft.PowerShell.Utility.Activities
Microsoft.WSMan.Management.Activities

For more information about adding an activity to the Toolbox from an assembly, see How to: Add Activities to the Toolbox.