PowerShell scripts are widely used, and many Windows admins are familiar with them. But they're not the only way...
to run code. PowerShell workflows offer an alternative -- and a few benefits -- to traditional scripting.
A workflow and a script are similar -- each consists of a series of programmatic steps or activities. PowerShell can interact with the Windows OS, as well as some server applications, at a low level. This enables an admin to script nearly any task imaginable. But PowerShell scripting has some limits; referencing .NET from PowerShell scripts can help overcome these limits. For example, .NET can create GUI interfaces for PowerShell scripts or perform mathematical operations not supported in PowerShell.
PowerShell workflows work in conjunction with the Windows Workflow Foundation (WWF), which is part of the .NET framework. WWF includes an API and a workflow engine to create workflows. Similar to scripts, workflows consist of a series of activities, each of which performs a certain task. Admins can string several activities together to build a complex PowerShell workflow.
These activities are modeled as .NET activities. The .NET framework contains a library of commonly used activities for creating .NET workflows. Administrators use this functionality to build their own activities and create similar workflows in PowerShell.
Limits to PowerShell
Because PowerShell scripts tap into the .NET framework for advanced capabilities, they are very powerful. However, PowerShell scripts are tied to an OS process. For example, when you open a PowerShell window and launch a PowerShell script, that window is tied to an OS process that becomes the runspace for the script. Essentially, the PowerShell window is a sandboxed environment.
This process-level isolation is useful in some instances, but it also can be problematic. For example, an admin opens a PowerShell window and creates a variable named $A (Figure 1). When the admin opens a second PowerShell window and tries to call the variable, PowerShell has no knowledge of the variable because all windows run in isolation.
Advantages of PowerShell workflows
PowerShell workflows are not tied to a PowerShell window, which allows them to run functions to numerous devices simultaneously. Admins also can run multiple workflows simultaneously and in parallel. This enables them to build runbooks with separate activities that run simultaneously, rather than consecutively, to efficiently handle tasks, such as virtual machine provisioning.
PowerShell workflows also solve a bigger problem. If a PowerShell script runs during a system reboot, all progress is lost and the script must run again. PowerShell workflows can check on the progress, which allows the task to continue after a reboot, loss of network connectivity or some other interruption. Additionally, Windows admins can build PowerShell workflows without having to learn .NET.
It is a good idea to construct long-running or complex scripts as PowerShell workflows. But remember: Not every PowerShell cmdlet is natively supported for use in workflows. However, Microsoft provides an InlineScript function that can run otherwise unsupported commands in workflows. In addition, multiple PowerShell workflows can run simultaneously, but each workflow has its own runspace. As such, other workflows may not recognize environmental changes, such as declaring a variable, that are made within a single workflow.
Attacks via PowerShell on the rise
PowerShell Direct helps with Hyper-V management
Steps to prevent unwelcome PowerShell script changes