When Windows PowerShell Met Workflow

When Windows PowerShell Met Workflow

Rate This
  • Comments 7

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?


- 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

Leave a Comment
  • Please add 5 and 4 and type the answer here:
  • Post
  • post a more concrete example......

  • Sadly, Microsoft and Windows is rapidly moving away from usable computing. The command line and powershell and the zealotry merely hide the fact that its a massively complex, inaccessable tech, only fit and viable for people who have a command line aptitude - thus only the highly specialised need apply.

    Multi paragraph installation commands replacing Setup.exe. Really? Are you for real? Oh wait, you guys are moving lock stock and barrel to a touch paradigm via the despicable garbage, Metro. How's touch and vast Powershelling going to gel. New meaning to joined up computing I guess.

    But then this is the company thats suggesting we fix Metro foul ups via Ketyboard short cuts.

    Nothing in the computing world moved mainstream until full and proper GUI was applied, and MS was built on it.

    But lets face it, MS would prefer to self host, and screw everyone else, including techs and partners. Good luck with that.

  • DMS, you really should look deeper, such as to statements made by MS at BUILD and elsewhere regarding the Desktop, or even to past posts on this blog regarding PowerShell's relationship with GUI management tools.

    The Desktop isn't going anywhere.

    Certain types of applications require it. Unfortunately, WinRT won't likely have coverage for Desktop scenarios in this release, which is why the focus for WinRT app development is currently Metro-styled apps The 'Modern' codename was a better moniker to convey that Metro and WinRT are separate things (i.e., you can have Metro-styled Desktop apps (see Zune, or the new Server Manager or Office 14). You just can't currently build them (as a supported scenario) using WinRT.

    Likewise, GUIs are going nowhere.

    Using Server Manager in Windows Server 8, or Exchange 2007+'s Management Console as examples (heck, even the Troubleshooter in Windows 7), you have your GUI management environment as always.

    The difference is these new admin GUIs run PowerShell scripts under the covers to perform the actions you're requesting when clicking around in the GUI.

    If your scenarios are covered by the GUI, you don't need to bother with PowerShell anymore than you do with the Command Prompt. However, if you'd like to go beyond the GUI to automate your common admin, setup, or other tasks, or include some logic specific to your environment that the GUI doesn't cover, then instead of being stuck with a GUI that only does some of what you need, you can use the underlying PowerShell scripts to build a solution that does meet your specific needs -- or, at the least, comes closer than the GUI can.

    The better GUIs that utilize PowerShell will let you export the actual script that would run, had you clicked the Finish button in a wizard, for example. Then you could save the script so you wouldn't have to click through the GUI the next time (or on the next machine). Just execute the script. Moreover, you can use that script as a starting point to customize it for your specific needs, and third parties could build GUIs atop those same scripts that go farther than MS' GUIs, filling gaps that otherwise would have to wait for the next release cycle.

    PowerShell is simply an automation tool.

    That statement belies the full utility PowerShell offers, but automation of common or tedious tasks is certainly core to its value. When you can test a process on one machine, then execute it across any number of machines (local or remote), or schedule it, put process to code to eliminate human error as much as possible (particularly for boringly repetitive tasks), there is great value in the tools enabling you to do so.

  • I really like the idea of orchestrating a workflow scenario with a Powershell script, specifically the ability to checkpoint/persist and resume long-running, batch-oriented tasks. Unfortunately I don't see any concrete examples of how to achieve this - just the bare bones workflow, parallel, sequence, etc constructs. Are there any more complete examples of how to automatically checkpoint a Powershell workflow on failure and restart it from the point-of-failure?

  • The document "WMF3 CTP2 Windows PowerShell Workflow.pdf" cannot be found on the MS download web site. Is there a more recent version?


  • I agree with @n4cer...

    I have been an admin for many years. One thing I missed when the GUI started popping up everywhere is the ability to do what PS now does. A GUI is good for a lot of things but if you have multiple servers to make changes on and administer the GUI is just not a practice or flexible enough tool. Being able to automate just about everything I do from a command line is something I love. I use PS every day. I can get stats of all sorts from a few keystrokes and have certain actions taken depending on those stats.  Now with workflows I'll be ale to do it faster, more efficient and do the work of multiple admins.

    If I want I can always use the GUI. As n4cer said the GUI's now just an interface to PS. Command line capability give more options. Moving to GUI only is extreemly limiting and cumbersome. Command line let's me do it how I want to. A GUI can only do so much because the programmers can't take every scenario into account.

    Option, options, options.

    - Johnny

  • DMS If you dont like what MSFT is doing you are free to go to the dark side and become a java developer, I love all Microsoft tools and new technologies and everytime something new is launched I embrace it and learn it, period.

Page 1 of 1 (7 items)