A client has a dedicated 24x7 Command Center Operations team that uses the Operations Manager console to monitor all Windows-based systems in the organization. This Command Center Operations team has restricted views that limit the alerts by "Source". It is critical that only specific alerts are viewable. Note the requirement was for the 24x7 Operators to see only known and legitimate Alerts without any noise on a single view. This is important because they already monitor several other Screens and systems for other non-SCOM alerts. The current solution works, but has a limitation. Due to a known bug in SCOM, there are issues with selecting both Rules and Monitors (under sources) in the same view. Last I heard there will not be a fix for this version. So at this point the view only displays Monitor-based alerts, but we need to start viewing Rule-based alerts as well. Based on the need need to display specific alerts from both Monitors and Rules in the same view, my thought was to use subscription(s) for the Alert selection and run a Command Channel to execute a Powershell script to update the Resolution State to a custom state specifically for the Command Center Operators. However I found that SCOM would only process 6 or so Alerts at the same time. Any more than that would not be updated. Another option and likely more efficient option is to develop a custom Connector that would only change the state. However it appears that subscriptions for Product Connectors are different that Notification subscriptions and you cannot choose specific rules and Monitors "Created by specific rules or monitors (e.g.,sources). Anyone have any suggestions or thoughts?

"Due to a known bug in SCOM, there are issues with selecting both Rules and Monitors (under sources) in the same view. Last I heard there will not be a fix for this version." Yeah, I think they need to fix their product instead of being so smug about their object model. It's one thing to have a bug, it's another to not care about repairing it ever. The product is SCOM 2007, and it's now late 2010.High time they fixed their bugs, all of them! I'm just amazed at how often we the users need to edit (hack) the xml or do some convoluted workaround for lack of features that are described as "by design". Sorry for the rant and no that doesn't help you at all.

Hi, I noticed this post and would like to share it with you for your reference. Hope this can give you some hints: OpsMgr 2007: Custom alert view with Rules and Monitors does not work as expected http://blogs.technet.com/b/smsandmom/archive/2008/10/14/opsmgr-2007-custom-alert-view-with-rules-and-monitors-does-not-work-as-expected.aspx Meanwhile, I know you have tried creating a script to do this, would you mind let us know the content of the script? Thanks.Nicholas Li - MSFT Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Thanks Nicholas, the link in your previous post is the "Known issue" I was referring to. The script I was referring to is below. I expected this to work without issues. However, it appear to only work for 4 new alerts that appear at the same time; any more that 4 will not be updated by the powershell script/command channel. Althought most of the time there will be only a couple alerts per minute or even less, but there are situation when 4 + alerts are raised at the same time. In these situation it is critical that Alert resolution is updated so the correct operators will see the alerts and take action as needed. I recall reading that there might be performance limitations on the command notification channel, but I don't have a reference handy and I have lots on my list this morning :). Powershell Script used for the Command channel notification script #### # Start Ops Mgr snapin, get Alert ID ### $rootMS = 'RMS.domain.int' #Initializing the Ops Mgr 2007 Powershell provider add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client" -ErrorVariable errSnapin ; set-location "OperationsManagerMonitoring::" -ErrorVariable errSnapin ; new-managementGroupConnection -ConnectionString:$rootMS -ErrorVariable errSnapin ; set-location $rootMS -ErrorVariable errSnapin ; $AlertIdArg=$args[0] $alertIdArg = $alertIdArg.toString() #remove "{" and "}" around the $alertID if exist if ($alertIdArg.substring(0,1) -match "{") { $alertIdArg = $alertIdArg.substring(1, ( $alertIdArg.length -1 )) } if ($alertIdArg.substring(($alertIdArg.length -1), 1) -match "}") { $alertIdArg = $alertIdArg.substring(0, ( $alertIdArg.length -1 )) } Write-Output `r Write-Output "The Alert ID is: $AlertIdArg" Write-Output `r ## # Update Resolution State ## $alert = get-alert -criteria "Id = '$($AlertIDArg)'" $alert.ResolutionState = '5' $alert.Update("") Write-Output "Successfully updated the resolution state" Write-Output `r ### # Remove the Ops Mgr PSSnapin ### Remove-PSSnapin Microsoft.EnterpriseManagement.OperationsManager.Client

How about just using Powershell and parsing all alerts you want and set them to that ResolutionState? $alert = get-alert |where{$_.name -eq 'Failed to Connect to Computer'}|where {$_.ResolutionState -eq 0} $alert.ResolutionState = '5' $alert.Update("") Downside of course is that in this instance you'd have to do multiple iterations for each specific alert you're looking for. If it's only a dozen or so then not so bad. The upside is that this wouldn't need to be done via a subscription notification, you could just run this script at a set interval. Don't know that this would work any better really, but I'm interested in seeing if you get this working.

Using powershell is a good option for cases involving only a few alert sources <~12 or so, like you stated. However I am working with over 200+ different monitors and rules.

Here is a link that I think references the issue you mentioned with more than 4 simultaneous alerts and notifications. http://blogs.technet.com/b/cliveeastwood/archive/2008/04/16/some-more-command-notification-tricks-and-tips.aspx This link seems to say this has been resolved with R2. http://blogs.technet.com/b/thiertho/archive/2010/01/04/alerts-management.aspx

Thanks for the links. I spent some more time investigating the issue. I found that a Command channel (that executes a VBScript) works well and can process at least 10 Alerts at a time. So there appears not to be any issue with this. However the Command channel that executes the powershell script does not work as expected. Sometimes it will execute for two alerts and other time it will execute against 4, but have seen no more than 4. I do not see the "Script or Executable was Dropped” Events (described in the link above) or any other Events indicating there was an issue.

I ended up finding a solution in different thread. I'm not sure why my Command Channel configuration wasn't working, but when I followed Layne's Command Channel config, it worked great. In fact I was able to process 80 alerts within 6 minutes. Here is the link to the other thread --> http://social.technet.microsoft.com/Forums/en-US/interopgeneral/thread/fd28474f-f9b1-4c3d-8189-fe9fe962d00a

Thanks for the update Mike.View OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/