Share via

Quick note: OpsMgr 2016 Shell requires at least PowerShell V3 - be aware when using SCORCH

What? Who cares? Who is still running PowerShell V2 or even V3?
You are absolutely right, but there is one use case where this is important:
Using OpsMgr 2016 module in System Center Orchestrator (SCORCH) 2012 (R2) / 2016 .NET script activities!

When you try to import the OpsMgr 2016 module with import-module in your .NET script activity, it will fail with an error message like:

 The module to process 'OperationsManager.psm1', listed in field 'ModuleToProcess' of module manifest
'C:\Program Files\Microsoft System Center 2016\Operations Manager\Powershell\OperationsManager\OperationsManager.psd1' 
was not processed because no valid module was found in any module directory.

Reason for this error: SCORCH 2012(R2)/2016 runs .NET script activities ONLY in PowerShell V2!


You can reproduce this behavior even if the module PSD tells us that it's minimal requirement is PowerShell V2...

... when you force your PowerShell to load in V2 mode you can see that it fails due to some .NET version requirements of the module's associated assemblies:



You will find blog posts on the net proposing the registry key HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\OnlyUseLatestCLR as a solution. DO NOT USE IT!!!!
Reason: See this excellent explanation:

Only working workaround is to capsulate PowerShell within the .NET script activity by calling:

  $result = powershell -scriptblock {import-module OperationsManager; get-scommanagementgroupconnection -computer myserver;...} 

This approach will load the latest installed PowerShell version and the OpsMgr 2016 module (and any other module that requires newer PowerShell versions) will run fine.
For a fully featured "best practice" template, my fellow PFE colleague and automation expert Jan Kratzer recommends: