Which PowerShell version is my SCOM agent using (or why I love SCOM 2012 R2 Update Rollup 7)

I have no idea how often I have used PowerShell scripts to build or extend SCOM Management Packs. Almost daily it must have been. Occasionally I stumbled over PowerShell version issues because the SCOM agent had its own logic of choosing a PowerShell version. To circumvent these, I basically limited myself to write (and test!!!) my scripts on PowerShell 2.0 and .NET 2.0 environments.

However; the world changed recently with the release of SCOM 2012 R2 UR7 and SCOM 2012 SP1 UR10. In the KB article the fixes are listed. Among many it says:

CLR load order change

The current behavior for agents is to choose a CLR version based on the operating system version. For Windows Server 2012 and newer, the .NET Framework 4.0 is loaded. For operating systems older than Windows Server 2012, the .NET Framework 2.0 family is loaded. On management servers, the .NET Framework 2.0 family is loaded. This essentially maps the .NET Framework version used to the version available out-of-box on the server. The problem with the current behavior is that even if the Management Pack author knows that .NET Framework 4.0 is present on the system, it cannot be used.

In the new behavior, the agent loads the .NET Framework 4.0 if it is available else it falls back to the .NET Framework 2.0.

What this do not easily reveal: Since .NET Framework 4.0 is now chosen, the SCOM agent and SCOM management server can use PowerShell 4.0 or 5.0. That is fantastic news. It means the SCOM agent (Microsoft Monitoring Agent respectively HealthService) is now making use of the most recent PowerShell version installed on an OS.


SCOM PowerShell module behaviour

When using the Windows Library’s PowerShell modules (e.g. Microsoft.Windows.PowerShellProbe), the following logic applies:

SCOM 2012 R2

Machine Type

<= 7.1.10218.0 (UR 6)

>= 7.1.10229.0  (UR 7)

Management Server / Gateway

PS 3.0 if installed; otherwise PS 2.0

PS 4.0 or 5.0 (if .NET 4.0 and PS >= 4.0 are installed)

PS 2.0 (if .NET 4.0 or PS >= 4.0 are not installed)


PS 2.0 / .NET 2.0

Note on legacy Windows versions: PowerShell 2.0 is the minimum requirement to use the agent’s PowerShell modules. And PowerShell is always installed or upgraded as part of the “Windows Management Framework”.

To verify that newer PowerShell versions are used after upgrading to SOM 2012 R2 UR 7, I wrote a simple MP with agent tasks. The following table shows the sample output of a Windows 2008 R2 system, having WMF 5.0 preview installed:

before UR7

with UR 7


System: Microsoft Windows Server 2008 R2 Enterprise

Host: OpsMgr PowerShell Host

Powershell Version: 2.0

Language Runtime .NET: 2.0.50727.5485



System: Microsoft Windows Server 2008 R2 Enterprise

Host: OpsMgr PowerShell Host

Powershell Version: 5.0.10105.0

Language Runtime .NET: 4.0.30319.34209



So at last I can start writing PowerShell workflows for SCOM in 4.0 or 5.0 manner – provided I can guarantee that every agent has UR7 or later installed!


Using PowerShell.exe as an alternative (System.CommandExecuterProbe)

When you look closely at the output of the table above, you can see that the PowerShell host is “OpsMgr PowerShell Host”. SCOM PowerShell modules are not running on Windows’ native PowerShell host (ConsoleHost). Instead a SCOM internal host is used, that is optimized for agent use. Occasionally this can lead to issues with very advanced PowerShell workflows.

If this happens, and only then (!) the following approach may be used. Instead of using the native SCOM PowerShell modules, the System.CommandExecuterProbe can call PowerShell.exe. However; you have to make sure, the execution policy for our workflow is set no stricter than “RemoteSigned”. Otherwise the script will not be run.

Examples for this are found in SharePoint MPs or were used back in SCOM 2007 days to run PowerShell scripts. Or have a look at my own sample MP linked at the end of this post.


PowerShell Environment Test Tasks (Management Pack)

The management pack linked below contains three diagnostic tasks, targeted at the HealthService object.

  • _Diagnose PowerShell Environment (PowerShellProbe)
  • _Diagnose PowerShell Environment (CommandExecuterProbe)
  • _Diagnose PowerShell Environment (CommandExecuterProbe with -version override)

They do provide output on the PowerShell environment used by the SCOM workflows. Essentially the objects $PSVersionTable and $Host are being reported.

PowerShell_TaskI am including both the unsealed pack and the VSAE project as a reference. Happy MP authoring.


List of all update rollup packages for the SCOM 2012 family

How to apply SCOM 2012 R2 UR 7 (by Kevin Holman)

Download: Check PowerShell Version Management Pack (XML)

Download: Check PowerShell Version Management Pack (VSAE Project archive)




PKI Certificate Verification Management Pack Update –

Many years have passed since I first published the certificate MP back in summer 2009. Almost 5 years(!) later this management pack still fills a gap by keeping an eye on PKI certificates installed locally in servers’ certificate stores. Certainly about time for an update.

Today I am able to release a major update – a complete re-write rather – of the PKI Certificate Verification MP. It is hosted over at SystemCenterCentral.com in the MP Catalog.

MP change history
  • SCOM 2012 / 2012 R2 support only (the legacy MP is still available for use on SCOM 2007).
  • main monitoring script now uses PowerShell instead of VB Script, making it compatible with any system locale and easier to maintain.
  • new, advanced certificate verification flag overrides
  • dashboard view
Some extra words on the effort

The main aim with this update is to make the MP’s code easier to maintain. Hence I first recreated the entire MP as a Visual Studio project with the Authoring Extensions. This involves taking apart the MP’s elements, adding each one as a separate item to a VS project structure. Next I started writing a new discovery and monitoring script based on PowerShell. This script does most of the work by essentially enumerating certificates and certificate revocation lists in local certificate stores. Due to limitations in PowerShell regarding CRLs and alternate certificate stores, this script got rather complex. No chance of getting away with something easy and straight forward as ‘ls cert:\LocalMachine’. With the first CRLs getting discovered, tests, more tests, some extra testing plus updating the documentation were left.

While I did not clock the hours, the update kept me busy in much of my spare and commuting time during the last 4 months. And I must mention everybody helping with code samples, advise, by testing and reviewing.  Pete, Vadim, Marc, Joel, Bob, Dan, Marnix, Stan, Tao and Dirk – this wouldn’t be here today without your help!

Certificate MP in VSAE

MP Solution opened in Visual Studio