Targeting workflows to Resource pools


Resource Pools in SCOM 2012 are an advancement over SCOM 2007, where a resource pool can be used to host instances, that have targeted workflows, and make them highly available.  This allowed the “All Management Servers Resource Pool” to host the instances that the RMS used to run in SCOM 2007.  This allowed for all management servers, in the AMSRP, to automatically load balance the old RMS workflows, across all management servers.

This also is used for thing like the Notifications Resource pool, which hosts two instances (or Top Level Managed Entities) which are the Pool object itself, and the “Alert Notification Subscription Server” which have many monitoring workflows target it to monitor the notification process health.


Well, we can also write workflows and target resource pools.  We might do this if we want a workflow to run on the management servers, but be highly available. 

In this example, I will take a VERY simple script that does nothing but log an event, and target the All Management Servers Resource Pool.

First, here is my PowerShell script:

$api = new-object -comObject 'MOM.ScriptAPI' $api.LogScriptEvent("momscriptevent.ps1",9999,0,"this is a test event")

This script simply loads the MOM.ScriptAPI which is necessary to perform specific SCOM actions in script, such as logging events to the SCOM event lot, creating property bags, submitting discovery data, etc.

Then, it logs an informational event for the script in the SCOM event log wherever it is running.

Next up – write my rule to run the script.

We cannot use the SCOM 2007R2 Authoring Console to write this rule, as we need to target the Resource Pool object which SCOM 2007R2 does not understand, nor can it reference.  If you are most familiar with authoring in that tool, and you really want to use that SCOM 2007R2 Authoring Console, you can do that, and just target something else, like “Windows Server Operating System” and then change the class later in an XML editor.

Here is my manifest section.  Note – I need to reference the SCOM 2012 versions of these MP’s since this MP will not work on SCOM 2007:

<Manifest> <Identity> <ID>Target.ResourcePool.Example</ID> <Version></Version> </Identity> <Name>Target.ResourcePool.Example</Name> <References> <Reference Alias="SC"> <ID>Microsoft.SystemCenter.Library</ID> <Version>7.0.8427.0</Version> <PublicKeyToken>31bf3856ad364e35</PublicKeyToken> </Reference> <Reference Alias="Windows"> <ID>Microsoft.Windows.Library</ID> <Version>7.5.8500.0</Version> <PublicKeyToken>31bf3856ad364e35</PublicKeyToken> </Reference> <Reference Alias="Health"> <ID>System.Health.Library</ID> <Version>7.0.8427.0</Version> <PublicKeyToken>31bf3856ad364e35</PublicKeyToken> </Reference> <Reference Alias="System"> <ID>System.Library</ID> <Version>7.5.8500.0</Version> <PublicKeyToken>31bf3856ad364e35</PublicKeyToken> </Reference> </References> </Manifest>

Next, my simple rule.  Notice – I target the AMSRP class, I add a simple scheduler module to run this workflows every 30 seconds, and I have a simple write action based on Microsoft.Windows.PowerShellWriteAction module.

<Monitoring> <Rules> <Rule ID="Target.ResourcePool.Example.RunSampleScriptRule" Enabled="true" Target="SC!Microsoft.SystemCenter.AllManagementServersPool" ConfirmDelivery="true" Remotable="true" Priority="Normal" DiscardLevel="100"> <Category>Custom</Category> <DataSources> <DataSource ID="SchedDS" TypeID="System!System.SimpleScheduler"> <IntervalSeconds>30</IntervalSeconds> <SyncTime></SyncTime> </DataSource> </DataSources> <WriteActions> <WriteAction ID="PoshWA" TypeID="Windows!Microsoft.Windows.PowerShellWriteAction"> <ScriptName>momscriptevent.ps1</ScriptName> <ScriptBody><![CDATA[ $api = new-object -comObject 'MOM.ScriptAPI' $api.LogScriptEvent("momscriptevent.ps1",9999,0,"this is a test event") ]]></ScriptBody> <TimeoutSeconds>30</TimeoutSeconds> </WriteAction> </WriteActions> </Rule> </Rules> </Monitoring>

That’s it!  I will post my full XML as a sample attached to this article.

Now, when I import this MP, ONE of my management servers should start running this workflow.  It will be whichever MS is hosting the AMSRP class at that time.  This could change as loads are reshuffled, or as management servers are taken down for maintenance.

I have three management servers, SCOM01, SCOM02, and SCOM03.  I can see this workflow is running happily on SCOM02:


I will stop the health service on SCOM02, or shut the OS down.

The last event I got from the test script was at 9:09:56 AM.

What happens now, is the other management servers are waiting for a heartbeat failure threshold to take a vote, and evict SCOM02 from the pool.  The SCOM database is also a “default observer” and plays a role in the voting process. 

At 9:12:36 AM, I start to see the pool manager events coming in, showing that they other management servers are redistributing the workflows.  My 9999 event is now being created on SCOM03, with my first event showing up at 9:12:55 AM, or about 3 minutes after SCOM02 went down.



My sample XML is provided below.

Comments (13)

  1. Back in November I blogged a variant of this that will make a SCOM-2007-safe MP. Although I’m curious if/how you could target a different
    resource pool. For example, I have a group of gateways in a remote data center that are in a resource pool. How could I target their resource pool? I never figured that one out.

  2. Mario says:

    Very usefull, thanks for sharing!

  3. Jonathan says:

    Had not thought about targeting resource pools in monitoring workflows before now. This can be useful in certain types of operational tasks that you might want to run in the management group. Previously, I would have targeted the RMSE, but will now target
    a resource pool. Thanks for the idea 🙂

  4. Bill C says:

    I created a couple of two-state script monitors targeting the AMSRP which works great, however, if I place one monitor into MMode, the entire pool goes into MMode. What targeting consideration am I missing?

  5. SK says:

    I am seeing resource pool workflow distribution issue on my setup.
    I have custom resource pool created. There were 2 management servers added to it. After a day or 2, I removed one of the servers from the resource pool.
    And SCOM is still distributing workflows to that management server. These workflows are targeted on the entities managed by resource pool.
    Can you provide any suggestions?

  6. Ehrnst says:


    I have written a PS script discovery wich i planned to run against the AMSRP but the discovery doesent seem to run. If i change target to “management server” it Works just fine. Is ther any thing i am missing?

    1. Kevin Holman says:

      if you change target to MS it runs on all MS in the pool. If you change it to target a pool, it will run only on the MS that hosts the instance of the pool class, which will be one of the MS in the pool.

      1. Hi Kevin

        Do you know if it’s possible to run a on-demand discovery task for a discovery that targets the AMSRP? And if so which target class instance should we provide? If I try using the target instance returned from say

        Get-SCOMClass -Name Microsoft.SystemCenter.AllManagementServersPool|Get-SCOMClassInstance

        the discovery task returns ‘DISCOVERY_NOT_FOUND’



        1. Kevin Holman says:

          I don’t. What’s the scenario?

          1. Thanks for asking 🙂 Well, here’s the scenario:

            Just as you’ve demonstrated monitors having the resource pool “All Management Servers Resource Pool” (AMSRP) as target, discoveries can also have AMSRP as target. An example of this, is the standard discovery “Discover Operational Database Watchers” of the management pack “System Center Internal Library”.

            During my development of management packs I usually run the on-demand discovery tasks (to speed up the discovery). However I’ve not been able to run the on-demand discovery task successfully for discoveries that targets the AMSRP. Every time the task result is ‘DISCOVERY_NOT_FOUND’.

            Here an example:

            $task= get-scomtask -name Microsoft.SystemCenter.TriggerOnDemandDiscovery

            $discovery = Get-SCOMDiscovery -DisplayName ‘Discover Operational Database Watchers’

            $target = Get-SCOMResourcePool -DisplayName ‘All Management Servers Resource Pool’


            $managementServer = (Get-SCOMManagementServer)[0]

            $instance=get-scomclass -name Microsoft.SystemCenter.HealthService| get-scomclassinstance | ?{$_.displayname -eq ($managementServer.DisplayName)}

            start-scomtask -task $task -instance $instance -override $overrides

  7. David Knight says:

    If I target a powershell script workflow at the AMSRP that uses the operationsmanager module to get information about the management group (such as get-scommanagementserver, get-scomresourcepool, etc.), it succeeds just fine running every 15 minutes until after roughly 24 hours, it begins to fail. If I restart the healthservice on the management server hosting the AMSRP, it will succeed once again for roughly 24 hours and then begin failing once more.

    Any idea what the cause and solution to that might be?

    1. Kevin Holman says:

      Yes David I have seen this very issue with my customers. It seems to happen when the SDK is very busy on a management server. Scripts running on the management server stop being able to reliably connect to the SDK, or load the SCOM module. What I have found is that Import-Module OperationsManager becomes unreliable. What I have done is change my custom SDK connecting scripts to use this, which seems to resolve the issue:

      #Connect to SCOM Management Group Section
      $MServer = “localhost”
      # Clear any previous errors

      # Import the OperationsManager module and connect to the management group
      $SCOMPowerShellKey = “HKLM:\SOFTWARE\Microsoft\System Center Operations Manager\12\Setup\Powershell\V2”
      $SCOMModulePath = Join-Path (Get-ItemProperty $SCOMPowerShellKey).InstallDirectory “OperationsManager”
      Import-module $SCOMModulePath
      $momapi.LogScriptEvent($ScriptName,9876,2, “Unable to load the OperationsManager module, Error is: $error”)
      New-DefaultManagementGroupConnection $MServer
      $momapi.LogScriptEvent($ScriptName,9876,2, “Unable to connect to the management server: $MServer. Error when calling New-DefaultManagementGroupConnection. Error is: $error”)

  8. Marc says:

    Hi Kevin,
    If I make a custom ressource pool with gateways, and I target workflows on it, will they really be executed on the gateways ?

    Since all the classes used for the ressource pools aren’t hosted, i doubt that my workflows will run on any management servers instead of the selected gateways.

    Thank you,

Skip to main content