07 Apr 2016

WMF 4.0 / .Net Framework Bug brakes Variable Scoping in Inlinescripts

In an earlier post I showed how-to-deal-with-variable-scoping inside PowerShell Workflows to be usable within InlineScript blocks. While the $USING way is simple and easy it conflicts with proper error handling inside InlineScripts.

First of all, the credits for filing the bug on connect, and writing first blog posts go to fellow MVP and PowerShell geeks Trond Hindenes and Ben Gelens.

I recently came across multiple SMA runbook issues, not limited to single customer, but it seemed to me quite randomly. And the worst: No one changed the Runbook code and they suddenly stopped to work. After investigating quiet a reasonable amount of time I notized that the variable rescoping within Inlinescripts ($USING:) was not working any more in some situations. That’s were I came across the blog post from Ben Gelens. I was able to reproduce the error in different ways. The root cause as Ben states correctly is $ErrorActionPreference variable which forces a bug in WF compilation, AND only if set to value “stop”. Setting $erroractionpreference = “stop” is something I often use inside PowerShell Workflows or regular PS Scripts, as it enables try catch statements on a script level. I’m pretty sure the bug was introduced by an update to the .NET / WMF components, but at this point in time I wasn’t able to figure out which KB could be the one in question.

Now when and where does this bug hit you?

  • On the WinRM Client Side (e.g. SMA Runbook Worker)
  • When using multiple InlineScript blocks in combination with WinRM to the same remote host inside a single workflow
  • When using nested runbooks with the above combinations

Preventing methods / Workarounds

  • Avoiding multiple InlineScript blocks within a single workflow to the same remote host
  • Avoiding $ErrorActionPreference = “Stop” inside the InlineScript blocks, use “-ErrorAction Stop” statements for CMDLETs where needed
  • Update SMA Runbook Workers with WMF5.0 (DISCLAIMER: Even this seems to work quite fine, it’s not yet officially supported by the Automation Team inside MSFT)


I’m happy to hear any other workarounds and thoughts.