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.
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.