Run a Monitor “Once” for all Instances of a Custom Class

I created a new class and a custom Discovery that reads a text file provided by our Networking team. When the discovery runs, all of 1,700 devices are “discovered” and show up in the correct class within SCOM (via the Discovered Inventory node).

My problem is that when the monitor I wrote runs, it runs 1,700 times causing an extended increase in CPU usage on the agent where this MP is targeted. Put simply, for each discovered object, the monitor starts, opens the text file, scans for its status, closes the file and the health state is updated if it changes.

What I think I would like to do instead is write a custom monitor that runs once for all 1,700 devices (for everything in that custom class) and only update the Health status for those objects that have a change in health (the text file is updated every 5 minutes). I think this would have the benefit of having only one monitor running that only opens the file once, thereby reducing the CPU spike.

Is that possible? And if so, are there any resources to reference?

Now, that said, I’m also looking at changing the discovery from a file based discovery to a database discovery, but I don’t know if that changes the problem enough since the monitor will still be running once for each instance of the class…


Hey Jelly,

Good suggestion! I’ll check it out in the next couple of days to see if it hits the mark. I’ll report back here with my results.



SCOM will already do this without you having to make something too custom - the problem here is probably that the script is not written to support Cookdown and takes in a varying property for each device instance (the ID to search the file for?) and is therefore forcing SCOM to run it multiple times, rather than reading the file once and replaying the data to all workflows that need it.

What you probably need to do is re-write the script to parse and output all relevant entries (regardless of which device it’s for) and then in the health expressions use a clause in each state that filters out entries from other devices.

And yes, if you switch to a database approach but still bind device specific info in your db query, you’ll run 1700 database queries (if you use a native OLEDB module it’ll perform better than a PS script, but will still probably murder the agent).

Agreed with Vyper, you very much should author your monitor to do cookdown, so the script would only run once for all of the 1700 instances.

There is a good video here that explains it

And also in technet :

However I don’t believe that using powershell to query a database would be much worse that a native oledb module, as long as you don’t use SQL specific cmdlet but stick to using native sql connection objects (as described here by K. Holman : )


Is it/could it be a PowerShell monitor? This popped up on my radar recently: - It would allow you to run the job in batches, rather than all at once.