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…

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 : https://blogs.technet.microsoft.com/kevinholman/2017/10/12/how-to-create-a-scom-group-from-a-sql-cmdb-query/ )

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).