Get started Bring yourself up to speed with our introductory content.

PowerShell workflows can overcome limits of scripts

PowerShell scripts have their strengths -- and a few glaring weaknesses. Use PowerShell workflows to get around a few common technical restrictions.

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.

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.

PowerShell windows
Figure 1. A variable created in one PowerShell window cannot be called from a second PowerShell window.

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.

Next Steps

Attacks via PowerShell on the rise

PowerShell Direct helps with Hyper-V management

Steps to prevent unwelcome PowerShell script changes

This was last published in April 2017

Dig Deeper on Windows PowerShell Scripting

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Which tasks are better suited for PowerShell workflows vs. PowerShell scripts?
Cancel

-ADS BY GOOGLE

SearchServerVirtualization

SearchCloudComputing

SearchExchange

SearchSQLServer

SearchWinIT

SearchEnterpriseDesktop

SearchVirtualDesktop

Close