When Windows PowerShell Met Workflow

Meet the new kid on the block! Windows PowerShell Workflow (PSWF) is the latest addition to the Windows PowerShell family.

First, let’s establish the context for the decision to integrate workflows into Windows PowerShell. It starts with cloud computing and Windows-based datacenters. Cloud computing provides a set of highly available, scalable computing services that leverage high volume components (servers, disks, RAM, etc.) High volume components are less reliable than their tier 1 counterparts and even those occasionally fail. The key to cloud computing is to use software to deliver a reliable service in spite of failures. Cloud computing management needs to be reliable in spite of failures. This is where workflows come in. Workflows are typically long-running scripts that are designed to survive component or network errors and reboots.

Automation is the heart of creating and running private and public clouds at scale. By automating administration tasks and operations, you decrease cost and improve repeatability, quality, auditing and logging. This allows you to increase your server-to-admin ratio, take on more business and increase the value of your employees by freeing them up to deliver higher value functions. As an example, Erin Chapple explains:

“Server Manager accomplishes this by leveraging the multi-machine management capabilities of WMI, Windows PowerShell and Windows PowerShell’s new workflow capabilities. Virtually every operation done using Server Manager can also be done via Windows PowerShell”.

While building Windows PowerShell Workflow, we took advantage of the scalability and maturity of Windows Workflow Foundation 4.0 (WF) to bring the benefits of workflows -- long running capability and reliability -- to scripters and the Windows PowerShell ecosystem.

In one sentence, Windows PowerShell Workflow is all about:

Reliably executing long-running tasks across multiple computers, devices or IT processes

Until Windows PowerShell 3.0, the approach to solving this problem has been to combine Windows PowerShell and Windows Workflow Foundation with proprietary implementations. As part of our planning process, we talked to many customers and found many cloud providers and hosters who took WF and Windows PowerShell and put them together. Hundreds of design decisions need to be made during that process so the workflows for any implementation did not work with other solutions. We wanted to deliver the definitive integration of these two technologies in a way that could be used out-of-the box or as a reusable library in a third-party solution. For example, we have designed our implementation with extension points that allow applications to host our engine in a fault tolerant, scale out configuration with detailed auditing. The goal is for the community to write workflows that work with our in-box solution and then light up without modification in third-party solutions.

In Windows 8, we introduce Windows PowerShell Workflow with two key goals:

- Minimizing the complexity of automating across a large number of cloud or datacenter computers and devices.

- Creating an ecosystem where ISVs and partners can build solutions on top of Windows PowerShell Workflow and the artifacts can be shared with the community and used in any solution.

To achieve these goals, we decided to invest in the following areas for our first PSWF release:

- Simplified workflow authoring

- Leverage your existing knowledge

- Reliable workflow execution

- Performance and Scalability

Simplified Workflow Authoring

Windows PowerShell Workflow enables IT professionals and developers to author sequences of activities that are long-running, repeatable, frequent, parallelizable, interruptible, suspendable, and/or restartable as workflows.

A workflow is a set of activities. An activity is an individual step within a workflow that performs a defined task, such as getting the list of virtual machines in a host computer.

Leverage Your Existing Knowledge

We designed PSWF with our sacred vow in mind:

We respect your investment in learning Windows PowerShell by reusing concepts over and over to make sure learning Windows PowerShell was the best thing you ever did.

This is very important to us: making the most of your time and leveraging the investment you have already made in Windows PowerShell instead of asking you to learn a whole new language for authoring workflows. We care deeply about your ROI, so instead of creating new workflow abstractions, we used and built Windows PowerShell abstractions with workflow semantics.

At the same time, we want to work within the existing Windows Workflow Foundation ecosystem. This is why you have two options for writing a Windows PowerShell workflow:

- PowerShell script-based workflow: If you know how to write PowerShell scripts, you can reuse your assets and skills and learn a few new constructs to create workflows. For instance:

• workflow
• inlinescript { }
• foreach –parallel
• parallel { }
• sequence { }

- XAML: If you have used WF or have existing XAML workflows from the community, your XAML workflows will still work in the PSWF world.

We will analyze these new constructs in the upcoming workflow posts to help you get started quickly.

Reliable Workflow Execution

Windows PowerShell Workflow helps you orchestrate the reliable execution of management workflows across multiple computers that target Windows and standard supporting devices in an IT environment.

To help increase the reliability and robustness of your workflows, we provide the following workflow features:

- Checkpoint-Workflow activity

- PSPersist parameter

- $PSPersistPreference variable

- Suspend-Workflow activity

Performance and Scalability

In addition to the areas above, we also invested heavily in improving the performance and scalability of the PSWF engine. Using PSWF, you can scale out workflow execution to thousands of managed nodes. The core investments that helped make this a reality are:

- Parallel Task Execution (parallel, foreach -parallel)

- Workflow Throttling

- Connection Throttling

- Connection Pooling

- Integration with the Disconnected Sessions feature

- PSWF Extensibility API

A set of future blog posts will analyze each of the investments above in detail.

 

Setup and Down-Level Support

Some of the questions we received after introducing this feature set and the investments above to our awesome Windows PowerShell MVPs were: “How do I install PSWF?” and “Can I use this feature set in down-level machines?” The good news is that Windows PowerShell Workflow ships as part of Windows PowerShell 3.0, which means that it is available wherever Windows PowerShell is installed. This includes the Server Core installation option, in which Windows PowerShell is available out of the box starting in Windows 8. PSWF is even available for down-level installations of Windows Server 2008 R2, Windows Server 2008 and Windows 7 via the Windows Management Framework 3.0 (Beta Release).

 

To Workflow or To Script… That is the Question

This post covered some of the common questions but the top five would not be complete without the following:

When should I write a PowerShell workflow vs. a script?

This question requires deeper analysis so we will answer it fully in a separate article. However, here are the basic reasons for writing a workflow so we help you start thinking about this.

For “Reliably executing long running tasks across multiple computers, devices or IT processes” you will typically need:

- Robustness (persistence, suspension and resumption capabilities, tracked execution)

- Enhanced PowerShell assets and skills (built-in library of management tasks, built-in parameters for multi-machine management, authoring workflows as scripts, workflow management through job cmdlets or APIs)

- Scalability and Reliability (parallel execution, connection and action retry, etc.)

If you need the above, you may want to consider writing a workflow instead of a regular script. More of this in an upcoming episode of Workflow awesomeness…

Show me the Money!

I know, I know, you can’t wait to get started! J Here is one of the most basic workflows you can write:

Now… How do you find it? How do you run it? How do you get help for it? So many questions, so little time! We wanted the answers to be as simple and as consistent with your existing knowledge as possible: Workflows behave just like every other Windows PowerShell command!

- How do you find it?

Get-Command Test-Workflow

Get-Command Test-Workflow -Syntax

- What is the proper way to name a workflow?

Verb-noun, just like you name any PowerShell cmdlet! Please remember to use approved verbs.

- How do you run it?

Test-Workflow

- How do you get help for it?

Get-Help Test-Workflow

- How do I run it against other computers?

Test-Workflow –PSComputerName ManagedNode1, ManagedNode2

- Will the awesome ISE Intellisense feature work for PSWF at some point?

That’d be a smart thing to do, wouldn’t it? As Cato said, patience is the greatest of all virtues.

But wait, there is more! Stay tuned for upcoming blog posts about using the new workflow common parameters such as PSComputerName and PSCredentials (the keys of the kingdom for running workflows in multi-machine environments), and the Windows PowerShell jobs and modules infrastructure for workflow execution. This is just the beginning!

Here is a sneak peak at what is coming next. These examples use some of the concepts that we will dive into during the next few weeks.

 

 

We Want You!

Now that you know the basics, we want to hear from you!

You can send feedback directly to the Windows PowerShell Workflow team by using the Windows PowerShell Connect site at http://connect.microsoft.com/powershell. We triage Connect bugs several times a week and make a point to add comments to each of the bugs.

While you wait for our next post, here are some additional resources about Windows PowerShell 3.0 and Windows PowerShell Workflow:

Getting started with Windows PowerShell Workflow (Download WMF3 CTP2 Windows PowerShell Workflow.pdf)

PowerShell v3: Workflow is the Flagship Feature (by Don Jones – PowerShell MVP)

PowerShell Workflow, Defined (by Hal Rottenberg – PowerShell MVP)

Rocking the Windows Server 8 Administrative Experience

TechNet docs on the Workflow module

Writing a Windows PowerShell Workflow in the Visual Studio Designer

SDK/MSDN documentation

We hope you enjoy the new Windows PowerShell Workflow functionality of Windows 8. We are having lots of fun building it!

Mir Rosenberg [MSFT]

Senior Program Manager

Windows PowerShell