If so, what would be the trigger for removing the override?

Although the 'outlook rule' suggestion is the safest I think.

Does anyone knows how to configure one alarm that plays a sound when becomes activated?

Or how can I add sound to one preconfigured alarm?

Thanks

$api=new-object -comObject "MOM.ScriptAPI"
$QMgrDiscoveryData = $api.CreateDiscoveryData(0, $SourceId, $managedEntityId)

$qmgrcoll = @(Get-WMQQueueManager)

foreach ($qmgr in $qmgrcoll)
  {
    $QManager = $qmgr.Name
    $QManagerDesc = $qmgr.QueueManagerDescription
    $QManagerCreate = $qmgr.CreationDateTime
     $QMgrDispName = $NetBiosName + "\" + $QManager
    $QmgrPathName = $ServerName + "\" + $QManager

    $QMgrInstance = $QMgrDiscoveryData.CreateClassInstance("$MPElement[Name='IBMMQ.Class.QueueManager']$")
    $QMgrInstance.AddProperty("$MPElement[Name='System!System.Entity']/DisplayName$", $QMgrDispName)
    $QMgrInstance.AddProperty("$MPElement[Name='Windows!Microsoft.Windows.Computer']/PrincipalName$", $ServerName)
    $QMgrInstance.AddProperty("$MPElement[Name='IBMMQ.Class.QueueManager']/PathName$", $QmgrPathName)
    $QMgrInstance.AddProperty("$MPElement[Name='IBMMQ.Class.QueueManager']/Name$", $QManager)
    $QMgrInstance.AddProperty("$MPElement[Name='IBMMQ.Class.QueueManager']/Desc$", $QManagerDesc)
    $QMgrInstance.AddProperty("$MPElement[Name='IBMMQ.Class.QueueManager']/CreationDate$", $QManagerCreate)

    Write-DebugInfo("Adding discovered Queue Manager instance to Discovery : $QManager")
    $QMgrDiscoveryData.AddInstance($QMgrInstance)
   
    Remove-Variable QMgrInstance
  }

Write-DebugInfo("Returning Discovery Data")
$QMgrDiscoveryData

So, regardless, all is working. If anyone knows the exact requirements of what is needed for a discovery like this (does it HAVE to be a component, have a relationship, and a key property?), I would greatly appreciate hearing from you.

there are times where I face really weird behavior in SCOM which make me angry, and they are always the same: Something is missing/doesn't work for no reason.

Most of the time it's because there is some caching/update problem with the Management Packs and in usual case it's easy to fix that: Stop Management Service, clear Health Service State folder, start it up again.

Actually, I'm tired of that as well since this makes the system quite unreliable.

So, my problem is pretty simple:

I have various Management Packs, each has a check, and each has 3 Groups and for each group an override. The 3 groups represent an Alert Priority, and the 3 Overrides, override the alert priority for the check.

When I import the Management Packs in my LAB environment, no problem, the Overrides are there. When I import them in my production environment, 50% of the overrides are missing. Some MPs work, some don't.

I checked the eventlog, nothing about faulty Overrides or anything. Also, when I check the Management Packs in the Health Service State folder it looks just fine.

So, if resetting the HSS folder doesn't help, any suggestions? I already tried to move the RMS to the other cluster node, didn't do the job either.

A little bit about the MP History:

We first had 3 Management Packs for each Check. The Check MP, the Discoveries MP, the Overrides MP.

We merged them since there was no reason to have a separate MP for each. Therefore I fear that it still has to do with faulty caching/.edb file.

Ideally someone can point me in the direction of a native module that will handle this.

Failing that, I have a couple of possibilities and I would appreciate some feedback.

1. Create a script (not powershell) that sleeps for the amount of time specified
   Service stops, state changes
   Diagnostic runs sleep then checks to make sure that the service is still stopped
   Recovery task starts the service if required
   
   This method is reasonably simple to implement but in one case the wait time is 30 minutes.  I'm not sure if I like the idea of a cscript process hanging around for that long.
    
2. Persist state to the registry
   A little more complicated.  Once the information is persisted in the registry a second trigger would need to be fired to check the persisted information.  This could possibly be a different workflow and would definately need a  bit of customisation
    
3. Any other suggestions?
   Has anyone done this or had a simliar requirement?

Although I'm not overly keen on either, I prefer the first option, it is relatively simple to implement, resource usage is low and a second workflow would not be required to support it. The script would be spawned and run outside the monitoringhost process so I assume that no other workflows would be delayed while it waits, please correct me if I'm mistaken.

Alternatively, does anyone know of a native workflow/method that could be used to persist custom information somewhere without running a script?  Maybe MS could include this in future releases if it does not exists already.

Part 5: OpsMgr 2007 and Powershell and the SDK – What MP does this class come from?