I've recently produced a couple of scripts that produce large, in memory objects that they're storing out to a CSV file as they go. My thread counts for Powershell are running high as I'm looping through several instances of these larger objects. Although my CPU and Memory are fine per the Resource Manager, the script is running very slowly and the thread count continues to rise.
Last time (Fixing OMS Workspaces) we looked a way to repair or distribute OMS Workspace settings using Powershell. Wouldn't it be nice if we could leverage SCOM's access to individual machines to be able to keep them attached to the workspaces? If we could pull this off, we could minimize the amount of time we're blind to each server in our environment. Why use SCOM to push OMS settings?
We've seen some interesting behaviors in Azure with the Healthservice Agent which provides the connection to SCOM in our hosted environment and OMS in Azure. The management groups registered with the service (Healthservice - Microsoft Management Agent - MMA for short) seem to disappear every once in a while. We suspect it happens during updates to the agent (extension if you're deploying from the Azure portal).
Sounds Fancy! The problem I was having was that SCOM doesn't have a default way to look at all of the members of a group/subgroup tree in a convenient way. The Get-SCOMGroup cmdlet doesn't have an option to recursively search any subgroups it finds. It requires all kids of clunky Powershell to enumerate all of that if you need it. I needed it.
Straight to the code: https://github.com/cole-mcdonald/SCOM-GhostedObjects
Microsoft's System Center Operations Manager has much more power than the interface allows access to. Of exceeding importance in an enterprise setting is building high availability into our systems. SCOM includes much of this by default in the management structures. The interface no longer reflects these settings, but they're still available to us through Powershell. Here's a little script I use in our environment for bringing new gateways online.
We've dealt with what types of data we can store in increasingly complex ways. It's time to start dealing with a discussion of "we've got it, what can I do with it? Let's start with the basics of object oriented programming. An object is an instance of a class. OOP, there it is!
If we think of our programs we're writing in terms of a series of blocks of code which accepts specific types of data in, does stuff to them, then hands them off to another block of code to do more stuff with, the method of moving that data becomes important. If it's all within a single computer, huge custom objects can be made and stuffed into a variable and that variable can be passed between each of the blocks of code to work on just the pieces of information it needs to do its specific job.