MP Authoring: Targeting RMS or MS?

I’m writing a write action module for a management pack that I’m currently working on. This module contains a PowerShell script that connects to SCOM SDK service and interacts with agent computers. I originally wrote the script and planed to target the workflow to the RMS. which I thought it would make sense because SDK service runs on it no matter whether the management group version is 2007 or 2012 (RMS Emulator).

My initial PowerShell code in the write action module looked something like this:

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.EnterpriseManagement.OperationsManager.Common") | Out-Null
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.EnterpriseManagement.OperationsManager") | Out-Null

$MGConnSetting = New-Object Microsoft.EnterpriseManagement.ManagementGroupConnectionSettings($Env:COMPUTERNAME)
$MG = New-Object Microsoft.EnterpriseManagement.ManagementGroup($MGConnSetting)

As you can see, I wrote the script to connect to the SDK on the local machine.

I was talking to a Microsoft SCOM PFE yesterday, and he asked me why not target the workflow to the Management Server class since in 2012, SDK runs on all management servers. Because I want this module to work on both 2007 and 2012, Initially I thought it’s not going to work on 2007 if I target the workflow to the management server class because the SDK only runs on RMS in 2007.

Anyways, I had another thought tonight, it would be nice if I could target MS instead of RMS to take the load off RMS and get each MS to only interact with the agents that are reporting to itself. This probably makes more sense and would be more efficient in 2012 rather than 2007.

So in order to make this script run on both 2007 and 2012, I changed the script to:

#Locate SDK service machine
$MachineRegKeyPath = "HKLM:\software\Microsoft\Microsoft Operations Manager\3.0\Machine Settings"
$MachineRegValueName = "DefaultSDKServiceMachine"
$regValue = Get-ItemProperty -path:$MachineRegKeyPath -name:$MachineRegValueName -ErrorAction:SilentlyContinue;

if ($regValue -ne $null)
$SDKServiceMachine = $regValue.DefaultSDKServiceMachine;
} else {
#cannot determine which SDK to connect

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.EnterpriseManagement.OperationsManager.Common") | Out-Null
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.EnterpriseManagement.OperationsManager") | Out-Null

$MGConnSetting = New-Object Microsoft.EnterpriseManagement.ManagementGroupConnectionSettings($SDKServiceMachine)
$MG = New-Object Microsoft.EnterpriseManagement.ManagementGroup($MGConnSetting)

Basically, the script now reads the default SDK service computer name from the registry of each management server and connect to this SDK machine instead of local computer. in 2007, this registry value points to RMS and in 2012, it points to the management server itself.

Of course, now that the script runs on multiple management servers, I had to rewrite the rest of it so it only interact with the agents on the local management server rather than the whole lot as if it’s running on the RMS.

The only concern I have with 2007 is, because my workflow runs on a schedule, when all management servers run this workflow at the same time, it will consume a large number of concurrent SDK connections on the RMS, which could be an issue in a large environment. to work around the issue, I would make sure that I make the SyncTime parameter overridable for the scheduler data source module so I can then create overrides for each management servers to run the workflow on different time window.


  1. Great blog. I am just starting authoring MP’s and you have benn very helpful. How would you retrieve the agents on the individual MS?

    Also, could you do a blog on how to add an attribute to the Windows Computer class? I would like to query Active Directory and add the managedby field from the AD Computer object and have it available as an attribute in SCOM 2012

    1. Hi Mike, please take a look at the SCOM 2007 R2 SDK documentation. you should be able to find it out there:
      basically, if you are using the SDK, you firstly connect to the management group, then get the management group administration object, then get management server (or servers), the management server object has a function to get all agents from this management server.

      In terms of adding another attributes, please take a look at the MP discovery video series from Brian Wren.

Leave a Reply

%d bloggers like this: