PowerShell Workflow for Mere Mortals: Part 3

Hey, Scripting Guy! So what’s up with Windows PowerShell workflows and activities? I do not know what an activity is. Can you help me?

—CJ

Hello CJ,

Microsoft Scripting Guy, Ed Wilson, is here. Ah…this afternoon, I am sipping a cup of Darjeeling Earl Grey tea with a bit of cinnamon stick, and I added just a bit of lavender honey from a nearby lavender farm. I am accompanying my tea with a 90% cocoa bar with black currants and hazelnuts. The combination is absolutely stunning.

Note This is the third in a five-part series of blog posts about Windows PowerShell Workflow for “mere mortals.” Before you read this post, please read:

Workflow activities

A Windows PowerShell Workflow is made up of a series of activities. In fact, the basic unit of work in a Windows PowerShell Workflow is called an activity. There are five types of Windows PowerShell Workflow activities that are available for use. The following table describes the types of activities.

Activity

Description

CheckPoint-Workflow (alias = PSPersist)

Takes a checkpoint. Saves the state and data of a workflow in progress. If the workflow is interrupted or rerun, it can restart from any checkpoint.

Use the Checkpoint-Workflow activity along with the PSPersist workflow common parameter and the PSPersistPreference variable to make your workflow robust and recoverable.

ForEach -Parallel

Runs the statements in the script block once for each item in a collection. The items are processed in parallel. The statements in the script block run sequentially.

Parallel

Allows all statements in the script block to run at the same time. The order of execution is undefined.

Sequence

Creates a block of sequential statements within a parallel script block. The Sequence script block runs in parallel with other activities in the Parallel script block. However, the statements in the Sequence script block run in the order in which they appear. Sequence is valid only within a Parallel script block.

Suspend-Workflow

Stops a workflow temporarily. To resume the workflow, use the Resume-Job cmdlet.

Windows PowerShell cmdlets as activities

Windows PowerShell cmdlets from the core modules are automatically implemented as activities for use in a Windows PowerShell Workflow. These core modules, all begin with the name Microsoft.PowerShell. To find these cmdlets, I can use the Get-Command cmdlet as shown here:

Get-Command -Module microsoft.powershell*

The command and the associated output from the command are shown in the image that follows.

Disallowed core cmdlets

However, not all of the cmdlets from the Windows PowerShell core modules are permitted as automatic activities for Windows PowerShell Workflows. The reason for this is that some of the core cmdlets do not work well in workflows. A quick look at the disallowed list makes this abundantly clear. The following table lists the disallowed core cmdlets.

Add-History

Invoke-History

Add-PSSnapin

New-Alias

Clear-History

New-Variable

Clear-Variable

Out-GridView

Complete-Transaction

Remove-PSBreakpoint

Debug-Process

Remove-PSSnapin

Disable-PSBreakpoint

Remove-Variable

Enable-PSBreakpoint

Set-Alias

Enter-PSSession

Set-PSBreakpoint

Exit-PSSession

Set-PSDebug

Export-Alias

Set-StrictMode

Export-Console

Set-TraceMode

Get-Alias

Set-Variable

Get-History

Start-Transaction

Get-PSBreakpoint

Start-Transcript

Get-PSCallStack

Stop-Transcript

Get-PSSnapin

Trace-Command

Get-Transaction

Undo-Transaction

Get-Variable

Use-Transaction

Import-Alias

Write-Host

Non-Automatic cmdlet activities

If a cmdlet is not in the Windows PowerShell core modules, it does not mean that it is excluded. In fact, it probably is not excluded. Therefore, when a non-core Windows PowerShell cmdlet is used in a Windows PowerShell Workflow, Windows PowerShell will automatically run the cmdlet as an InlineScript activity.

An InlineScript activity permits me to run commands in a Windows PowerShell workflow, and to share data that would not be otherwise permitted.

In the InlineScript script block, I can call all Windows PowerShell commands and expressions and share state and data within the session. This includes imported modules and variable values. For example, the cmdlets listed in the previous table that are not permitted in a Windows PowerShell workflow, could be included in an InlineScript activity.

Parallel activities

To create a Windows PowerShell Workflow that uses a parallel workflow activity, I use the Parallel keyword, and I supply a script block. The following workflow illustrates this technique:

WorkFlow Get-EventLogData

{

Parallel

{

Get-EventLog -LogName application -Newest 1

Get-EventLog -LogName system -Newest 1

Get-EventLog -LogName 'Windows PowerShell' -Newest 1 } }

When I run the script that contains the Get-EventLogData workflow, I go to the execution pane of the Windows PowerShell ISE to execute the workflow. What happens is that the three Get-EventLog cmdlet commands execute in parallel. This results in a powerful and quick way to grab event log data. If I call the workflow with no parameters, it runs on my local computer. This is shown here:

The cool thing is that with a Windows PowerShell Workflow, I automatically gain access to several automatic parameters. One of the automatic parameters is PSComputerName. Therefore, with no additional work (this workflow does not exist on Server 1 or Server2—it only exists on my workstation), I can use the automatic PSComputerName workflow parameter, and run the workflow on two remote servers. This is shown here:

Because I am not accessing the PSComputerName automatic parameter directly within my Windows PowerShell activity, I am actually using an automatic workflow parameter. For more information, see the following online Help: about_WorkflowCommonParameters.