Up here in the North Country the chill of the fall weather is just starting to set in. Over the next few months we'll hit some bone chilling temperatures and dig out the long-underwear. Nothing warms the heart and soul like a hearty bowl of soup, especially one perfected through the years with a bit of Grandma's love. If Grandma has taught us anything, it's that when you serve her soup you don't use a teaspoon - you use the ladle.
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.
My wife rolls her eyes every time I pull out Microsoft’s Power BI to analyze our personal bank statement data. Perhaps she doesn’t want me to know how much she spends each month on Starbucks Grande Chai Lattes… no whip. The reality is, I utilize Power BI whenever possible. In fact, these days I find it hard to engage in a business intelligence strategy discussion without Power BI being part of the conversation.
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.