SMA Step 1: Getting Comfortable with PowerShell Workflow (did you know?)

As you may be aware by now, Service Management Automation, the next generation of IT process automation from Microsoft, someday replacing System Center 2012 Orchestrator.

But are you aware of the differences between PowerShell and PowerShell workflow? Here are just a few:

  • PowerShell Workflows are not actually executed in PowerShell! PowerShell translates your script into XAML and hands it off to the WF, which is a portion of the Microsoft .NET Framework. WF accepts the XAML and actually performs the execution.
  • Workflows can’t do everything that a Windows PowerShell script could do. As you’ll learn throughout Don Jones’ series (below), anything you can’t translate into something WF understands is out of bounds. There are definitely a few aspects of Windows PowerShell that won’t transfer. So a workflow is neither a subset of Windows PowerShell nor a superset. It’s a mixed bag.
  • Workflows can also execute things in parallel, if you like. For example, if you have a set of tasks that can run in any order, with no interdependencies, then you can have them all run at more or less the same time. That shortens the amount of total time it takes to complete the workflow. If you are familiar with Orchestrator, you will love this!
  • PowerShell workflow makes heavy use of PowerShell remoting. This is something I do in Orchestrator already, so this is good news!

The fact that WF executes a workflow, and not Windows PowerShell, introduces some interesting complexities, but also some great capabilities.

  • For example, WF is designed to checkpoint the progress of a workflow. That way, if the machine running the workflow is interrupted in some way, such as shutting down, the workflow can pick up where it left off when the machine starts again.
  • You can also have workflows manually suspended and resumed.

Okay, hopefully that has peaked your interest. Time to get reading!

Getting up to speed

PowerShell MVP Don Jones was writing a 12-part series on PowerShell workflow that was interrupted when the magazine was discontinued. Below are the first 6 installments in the series (Jan to Jun 2013), followed by MVP Richard Siddaway’s PowerShell Workflow articles on The Scripting Guy blog.

PowerShell Workflow Articles in TechNet Magazine

http://technet.microsoft.com/en-us/magazine/jj884462.aspx

http://technet.microsoft.com/en-us/magazine/jj937192.aspx

http://technet.microsoft.com/en-us/magazine/jj992577.aspx

http://technet.microsoft.com/en-us/magazine/dn151046.aspx

http://technet.microsoft.com/en-us/magazine/dn170429.aspx

http://technet.microsoft.com/en-us/magazine/dn235766.aspx

More of the series on Scripting Guy Blog

http://blogs.technet.com/b/heyscriptingguy/archive/2012/12/26/powershell-workflows-the-basics.aspx

http://blogs.technet.com/b/heyscriptingguy/archive/2013/01/02/powershell-workflows-restrictions.aspx

http://blogs.technet.com/b/heyscriptingguy/archive/2013/01/09/powershell-workflows-nesting.aspx

http://blogs.technet.com/b/heyscriptingguy/archive/2013/01/16/powershell-workflows-job-engine.aspx

http://blogs.technet.com/b/heyscriptingguy/archive/2013/01/23/powershell-workflows-restarting-the-computer.aspx

http://blogs.technet.com/b/heyscriptingguy/archive/2013/01/30/powershell-workflows-using-parameters.aspx

http://blogs.technet.com/b/heyscriptingguy/archive/2013/02/06/powershell-workflows-design-considerations.aspx

http://blogs.technet.com/b/heyscriptingguy/archive/2013/02/13/powershell-workflows-a-practical-example.aspx

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.