PowerShell v3 Workflow Overview Day 1

A Roadmap for PowerShell Workflows
To teach myself workflows I have decided to RTFM for once. I am pulling this (and subsequent articles) straight from the Technet help, so, if it looks identical to the help, it should because it is. Mainly, my hope is to read through it and give a non-speakerphone rendition of the speaking points of the technology. I am mainly regurgitating it, because thats how I learn best, and, adding points of interest, clarifications, examples, errors, and, analysis the articles themselves do no touch.

Before I get started, here is the main road map from which I will be drawing throughout this series of articles. The day being reviewed will be set in bold and italicized to give a clear indication as to where we are at.

• Getting Started with Windows PowerShellWorkflow
• Writing a Script Workflow
• Adding Nested Functions and Nested Workflows
• Running Windows PowerShell Commands in aWorkflow
• Making a Workflow Suspend Itself
• Restarting the Computer in a Workflow
• Adding Custom Activities to a Script Workflow
• Adding Checkpoints to a Script Workflow
• Writing Help for a Script Workflow
• Saving Your Workflow in a Module
• Workflow Authoring Reference Topics
• Syntactic Differences between Script Workflowsand Scripts
• Using Activities in Script Workflows
• Using Variables in Script Workflows
• Configuring Your Workflow Environment
• Running a Windows PowerShell Workflow

Unfortunately, these first few posts will be pretty lifeless for the most part simply because Im given nothing with which to work. As I get more examples that I can actually do something PowerShell-related with, I will immediately go there.

1) Getting Started with Windows PowerShell Workflows
The key starting point with workflows is to get a grip on what they are. There are a lot of details and mechanics about the full particulars, so, I will start with the basics to try and build a sound foundation. As noted in the documentation,

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 1) author sequences of multi-device management activities, 2) or single tasks within a workflow, as workflows.

 Key design features for workflows can be:

• long-running
• repeatable
• frequent
• parallelizable
• interruptible
• stoppable
• restartable
• suspended and resumed
• and also continue after an unexpected interruption, such as a network outage or computer restart.

The groundwork for PowerShell workflows actually stems back to an earlier framework, Windows Workflow Foundation (WWF), from earlier .NET releases and relies inherently, but, not solely, only XAML, which, when unacronymized, refers to proprietary markup language means eXtensible Application Markup Language. You can see examples of early WWF models in this article from 2005 for historical reference: Introducing Microsoft Windows Workflow Foundation: An Early Look.  XAML was a native feature of Visual Studio, so, people did not really sit around write agonzingly long workflows by hand. They were designed and stored as XAML. PowerShell picks up by utilizing the pre-existing ecosystem build by Visual Studio and running with it.

More explicitly workflows can be created in two ways:

1. Authored/defined using PowerShell syntax. This can be explored at this to-be-explored-later link: Writing a Script workflow.
2. With XAML via Visual Studio. This also can be explored at length: Creating and importing workflows by using the Visual Studio Workflow Designer.

One important note to be made here is that the RunAs function available to workflows allows for custom session configurations which can allow delegated or subordinate staff for full or subsets of activities within a workflow.

A key concept in workflows is that of the activity. Put simply, an activity is a specific task you want a workflow to perform. The natural parallel would be an action you would use a function, cmdlet or function for in a regular script. It is key to understand, everything in the workflow world revolves around this activity notion. For instance, workflows are composed of one or more activities which are then:

1. Carried out in sequence
2. Carried out as a single command in another script
3. Use as an activity within another workflow

In this introductory article no examples were given to illustrate what these specific terms might look like in actual usage, so, I will have to do some "remember when I said X, well, this is what it looks like in practice." 

Benefits of using Workflows

Some of the key points that make Workflows worth looking into are:

• Windows PowerShell itself can be used to author workflows without the requisite Visual Studio or XAML knoweldge.
• As with many v3 PowerShell features, workflows can use the fan-out approach, where a wide array of machines can be managed.
• Tasksets can range from very simple (customized data-gathering) to extremely complex (such as server provisioning).
• Through the use of checkpoints you can control the stability of a given workflow in the face of both planned (reboots) and unplanned interruptions (BSODs). Checkpoints allow you to ensure that a workflow completes in spite of system instability and downtime.
• In the case of network connectivity issues users can connect/disconnect to the machine running the workflow. For example, if I need to reboot my machine because a workflow completed, this will not phase a separate running workflow on a different machine.
• As with PowerShell scripts/cmldets, workflows can be set up as scheduled tasks.

How Windows PowerShell Workflow and Windows PowerShell scripts differ

Again, more boiler plate regurg, but, key details to know for later when you start blowing things up.

These are major differences between workflows and plain old scripts:

• In scripts, the entire script is run in a single runspace. By virtue of this fact, the OS, defines which commands, variable and other elements are available. 
• Workflows however are composed of multiple activities each of which run in their own runspace. 

Takeaway: Scoping is extremely important as top level workflow variables are available to all runspace, whereas those defined at the script or command level are accessible only at their respective levels.

Below is a quicklist of points to help you know when considering a workflow will help you more than a regular script:

• 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.

There is no right number of checks that mean its time to jump on the workflow bandwagon. These are just good ways to see if you situations scale, requirements, precision tuning, and/or complexity make workflows the right call for the job.

If you dont want to work directly with the XAML editor you can tap into the cmdlets provided with Windows in the 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 

To do this, you have to dig into the .NET Framework. You can do this easily by using Doug Finkes excellent article (How to Load .NET Assemblies in a PowerShell Session). For instance, if you needed to add the first assembly use this command:

Add-Type-AssemblyName Microsoft.PowerShell.Activities

Once added, you can then work with the objects and their members stored in this assembly as if they are directly in your PSSession from the start. But, if you can use the Windows PowerShell syntax to accomplish the same thing, that seems like the long way around the block. If you are bent on using the XAML designer in Visual Studio, be sure to visit this link before trying to go at it purely from the shell: Using the Workflow Designer. If we want to see what a default v3 PSSession contains lets look at the appdomain:

[AppDomain]::CurrentDomain.GetAssemblies() |select manifestmodule| sort manifestmodule

From this single call alone its clear a large number of the objects used by the XAML editor are automatically loaded from the GAC into the PSSession on load.

CommonLanguageRuntimeLibrary

Microsoft.CSharp.dll

Microsoft.Management.Infrastructure.dll

Microsoft.PowerShell.Activities.dll

Microsoft.PowerShell.Commands.Management.dll

Microsoft.PowerShell.Commands.Utility.dll

Microsoft.PowerShell.ConsoleHost.dll

Microsoft.PowerShell.Security.dll

PSGenericEventModule

RefEmit_InMemoryManifestModule

System.Configuration.dll

System.Configuration.Install.dll

System.Core.dll

System.Data.dll

System.Data.SqlXml.dll

System.DirectoryServices.dll

System.dll

System.Management.Automation.dll

System.Management.dll

System.Numerics.dll

System.Security.dll

System.Transactions.dll

System.Web.dll

System.Web.Extensions.dll

System.Xml.dll

If you are bound and determined on how to use the XAML editor in Visual Studio to generate some XAML input, use this link: How to: Add Activities to the Toolbox.

Overview

So, we didnt get too far into the actual Workflow code, but, we have a better base from which to start building an idea of how the workflows fit in the whole picture. In tomorrows post, Writing a Script Workflow, I will actually touch a good bit of code, so, enjoy the break off from PowerShell for now.

Related Post: