Share via

PowerShell Workflow Gotchas

  • Article

PowerShell Workflow was introduced in PowerShell 3.0, and  further enhanced in later versions. Although PowerShell Workflow uses PowerShell syntax, it is build upon Windows Workflow Foundation (WWF) which is more complex.  When building a workflow in PowerShell it is actually translated into the language WWF leverages, XAML. Due to this architecture, there are several gotchas to be aware of since not everything which works a certain way in "regular" PowerShell necessarily will not work the same way in Workflow. The purpose of this Wiki article is to highlight the differences and things to be aware of. It will contain both content and links to external articles providing valuable information.

 

Gotcha #1

Do not use internal WWF variable names, such as Id, for workflow parameters. For example, creating a child workflow containing a parameter named Id will cause a parent workflow to fail with the error "Could not find a parameter named 'Id'. " Using a different parameter name resolves the issue

External articles

Be cautious with profile customizations and PowerShell Workflow (PowerShell Magazine)

Service Management Automation

Service Management Automation (SMA) is a new component in System Center for process automation.

From an architecture level there are similarities between System Center Orchestrator (SCO) and Service Management Automation (SMA). 

The main difference in the user experience is that SCO has a graphical interface with drag-and-drop support, while SMA is 100% based on Windows PowerShell Workflow.

Since SMA is leveraging PowerShell Workflow, a PowerShell user would expect everything working in PowerShell Workflow to also work in SMA runbooks. However, there are some gothas on this topic, which this article also will cover.

SMA gotcha #1

When defining a workflow in PowerShell, writing a comment at the last line works fine:

workflow Get-WorkflowSample  

{ 

  foreach ($item in $collection) 

{     } 

#end foreach 

 } 

#end workflow

When the same workflow is defined in SMA, it fails with an exception stating "Missing closing '}' in statement block". Removing #end workflow in the above SMA runbook resolves the issue.

SMA / Azure Automation gotcha #2

I have a script that runs in PowerShell, but not in Workflow (SMA or Azure Automation).  My script uses piping to pass objects from one cmdlet to another.  Why do I get an error when using PowerShell Workflow? The cmdlets are failing with an error message similar to the following (this was generated when trying to use an Azure VM object as a parameter):

Cannot bind parameter 'VM'. 

Cannot convert the "Microsoft.WindowsAzure.Commands.ServiceManagement.Model.PersistentVM" value of type "Deserialized.Microsoft.WindowsAzure.Commands.ServiceManagement.Model.PersistentVM" to type "Microsoft.WindowsAzure.Commands.ServiceManagement.Model.IPersistentVM". 

(Cannot bind parameter 'VM'. 

Cannot convert the "Microsoft.WindowsAzure.Commands.ServiceManagement.Model.PersistentVM" value of type "Deserialized.Microsoft.WindowsAzure.Commands.ServiceManagement.Model.PersistentVM" to type "Microsoft.WindowsAzure.Commands.ServiceManagement.Model.IPersistentVM".

(Cannot convert the "Microsoft.WindowsAzure.Commands.ServiceManagement.Model.PersistentVM" value of type "Deserialized.Microsoft.WindowsAzure.Commands.ServiceManagement.Model.PersistentVM" to type "Microsoft.WindowsAzure.Commands.ServiceManagement.Model.IPersistentVM".))

 

This is because PS Workflow stores complex objects in a deserialized format in order to enable checkpointing (workflow must be able to persist the data to be able to resume).  You are passing a complex object as a parameter to a PowerShell cmdlet and it received [Deserialized.ParameterType], when it was expecting [ParameterType].

Wrap any cmdlets that generate complex objects that are being passed as parameters to another cmdlet in InlineScript (both cmdlets should be wrapped in same inlinescript) to solve this problem. 

SMA / Azure Automation gotcha #3

I am seeing the following error message: "Root element is missing".  

This error message is frequently related to calling child runbooks.  You cannot call runbooks from within an InlineScript so simply moving the call outside of the inlinescript will solve this problem. 

**Azure Automation **

Azure Automation is SMA's online counterpart.  The experience in Azure Automation is almost exactly the same as in SMA, except that you need to create Automation Accounts which serve as containers for your runbooks and assets.  

Azure Automation gotcha #1

I am working in Azure Automation and keep getting the following error message: “ForbiddenError: The server failed to authenticate the request. Verify that the certificate is valid and is associated with this subscription.”  Why am I seeing this?

This error message is referencing your Azure Management certificates.  Make sure that you have your Azure management .pfx certificate added as a certificate asset in Azure Automation, and that .cer part of the certificate set up in Azure as a Management Certificate.  For a detailed tutorial on getting your certs properly set up, follow this blog: “Managing Azure Services with the Microsoft Azure Automation Preview Service”.

UPDATE - you can now authenticate using Active Directory.  Its much easier than creating certificates.  To learn more, see http://azure.microsoft.com/blog/2014/08/27/azure-automation-authenticating-to-azure-using-azure-active-directory/.

External articles

 

PowerShell Workflow resources