OpsMgr Self Maintenance - Health Rollup when Acknowledged

Dashboard Server
,
1

Hi community,

I have a question about the management pack called OpsMgr Self Maintenance by Cookdown.
I am doing a health rollup of groups of instances (Servers, network equipment etc.)
The rollup is working just fine, but I would like to know if were possible to somehow exclude alerts from the rollup that has been acknowledged?
So that the rollup becomes green, if alerts in the rollup are acknowledged.

We are using the health rollup on a world map of our locations, and if a rollup shows red, it will appear on the map. But we want the location to appear green, if one of the technicians has acknowledged all the red alerts.

2

I don’t believe that this is possible using just rollups.
Alerts are raised by monitors (or rules), but they don’t really link all that tightly. The health of the monitor is not directly relevant to the alert other than tying into the closed state. 2019+ cares about this more than earlier versions.

I have seen people write custom monitors to track alerts, with varying complexities and overheads, so that may be an option. However, if you’re looking at group rollups I suspect the overhead in this scenario would be high.

I’m struggling to work out how the Self Maintenance pack fits into this. Can you go into this bit further? That might be what I’m missing from this?

3

Thank you for trying to answer my question :slight_smile:

I can try to explain what my goal was in the first place, and the history behind it.

So, we wanted a dashboard showing all of our locations in the world. Our locations was marked as a dot on a world map. The dot would then either be red, yellow or green depending on the health rollup. The health rollup were first created with distributed applications aka. enterprise applications. This was just somehow to complicated for what we wanted. We simply wanted to group up the servers, and network equipment of that location. I later found out that we could do this with the OpsMgr Self Maintenance management pack by Cookdown.
This was a simple solution, where I could easily group up the equipment by location, and then activate the health rollup by configurating the health rollup through the management pack.

But then, when we have an alert, it should of cause be shown in the health rollup, and it does excactly this now, but then when a technician has ackowledged the alert, it would be nice to have the health rollup show as green.

I hope this somehow clarify my goal. :slight_smile:

4

OK, that makes sense. So you run the task from the self-maintenance pack to create the rollup monitor on the group, but otherwise, this is unused.

I can see what you’re trying to do. But I’m not sure I have an easy or advisable solution for you. Because of the disconnect between the monitor and the alert, there’s no feedback in the way you need.

The only way I can think of doing this is by using a PowerShell monitor to check if any object in the group has alerts in any ‘pending’ state instead of the rollup. This would probably be very heavy on the processing requirements. Cookdown (the internal SCOM process not the company), might be able to take the edge off this, but off the top of my head, I’ve not got a clear idea of how this would look.

I’ll have a play around in my lab later and see if I can come up with something workable. I’ll defer to any other ideas that come up as I’m not sure how workable this would be, even if it is possible.

1 Like
5

I’ve not been able to get this to work unfortunately, but I think I’m close.
Loosely I was following the monitoring section of this PowerShell MP blog. But was attaching the unit monitor to the group class.

The script I’ve been using so far is:

param([string]$Arguments)

$ScomAPI = New-Object -comObject "MOM.ScriptAPI"
$ScomAPI.LogScriptEvent("test",9999,2,"this is a test")

Import-Module OperationsManager

$Objects = $null
$Objects = @{}

function Format-Id ([guid]$Id) {
    "$($Id.Guid)"
}

function Get-Parents ($ObjectId, $State) {

    $Id = Format-Id $ObjectId

    if ($Objects.ContainsKey($Id)) {
        
        $Object = $Objects.$Id

        switch ($True) {
            ($Object.state -eq "Error") {
                return
            }

            ($State -eq "Error") {
                $Objects.$Id.State = $State
                $Object.Parents.foreach({
                    Get-Parents $_ $State
                })
                return
            }

            ($Object.state -eq "Warning") {
                return
            }

            ($State -eq "Warning") {
                $Objects.$Id.State = $State
                $Object.Parents.foreach({
                    Get-Parents $_ $State
                })
                return
            }
        }
        return
    }
    
    #Get parents and add them to cache
    $Item = Get-SCOMClassInstance -Id $ObjectId
    $Parents = $Item.GetParentMonitoringObjects() | Foreach { Format-Id $_.id }

    $Objects.Add($Id, @{Parents = $Parents; State = $State})

    $Parents.foreach({
        Get-Parents $_ $State
    })
}

$Alerts = Get-SCOMAlert -Criteria "ResolutionState < 249 AND IsMonitorAlert = 'true'"

foreach ($Alert in $Alerts) {
    Get-Parents $Alert.MonitoringObjectId $Alert.Severity
}

Get-SCOMGroup | foreach {
    $PropertyBag = $ScomAPI.CreatePropertyBag()
    
    $Id = Format-Id $_.Id

    $PropertyBag.AddValue("Id", $_.DisplayName)

    if ($Objects.ContainsKey($Id)) {
        #@{Id = $Id; State = $Objects.$Id.state}
        $PropertyBag.AddValue("State", $Objects.$Id.state)
    }
    else {
        $PropertyBag.AddValue("State","Healthy")
        #@{Id = $Id; State = 'Healthy'}
    }

    $PropertyBag
}

In theory this looks up all the matching alerts, and the parent objects, storing the worst state in a hashtable. It then looks up all the groups and sees if the ID is in the hashtable.
In theory then the monitor should be able to correlate the ID back to the object and use the state to determine the health. You could then remove the rollup monitor and use the PowerShell montor for state instead.

I think that its failing to look up the ID on the SCOM side, but I’m not completely sure. Maybe someone else can spot what I’m doing wrong or has a better idea. When I returned a pure Guid I was getting a type mismatch for each group.

6

This is much appreciated.
I was thinking to do it the powershell-way myself, or simply putting the objects in maintenance mode, but I just don’t think these are good solutions.
I think there is to much work and effort to put into this, versus what you get out of it ind the end.

But again, your work is much appreciated - I hope you are doing this in your own interest, and not only to please me :smiley:

7

No worries! Yes, it’s just that, I’m curious to see if it can be done or not!

A bit of a workaround, but (assuming this world map is with SquaredUp) you could put an alert tile alongside to show unacknowledged alerts?

1 Like
8

That is actually not a bad idea :slight_smile: I think I will do that for now.

1 Like