Showing posts with label SCOM 2012. Show all posts
Showing posts with label SCOM 2012. Show all posts

Friday, January 23, 2015

[OpsMgr 2012] Effective configuration dashboard : What Rule and Monitors are running on my server ? (#Dashboard #SCOM2012 #OpsMgr)

All SCOM professsionals have already been asked "What Rule and Monitors are running on my server ?" and there is no easy way to answer ! In SCOM 2007 there was a Resource kit "effective Configuration viewer" and for SCOM 2012, a new cmdlet has been introduced : Export-SCOMEffectiveMonitoringConfiguration but the result is not user friendly !

PS C:\> $Members = (Get-SCOMGroup –DisplayName "All Windows Computers").GetRelatedMonitoringObjects()
PS C:\> $Members | ForEach-Object { Export-SCOMEffectiveMonitoringConfiguration –Instance $_ -Path "C:\temp\$($_.DisplayName).csv" } –RecurseContainedObjects }



Thom Davis have studied the question and created a Dashboard. Here are the 2 articles that explain how it's made :



His Dashboard also is able to list :
  • Objects and classes on a selected computer
  • Active alerting Rules and Monitors for the selected computer
  • Active non-alerting Rules and Monitors for the selected computer
  • Non-active Rules and Monitors for the selected computer
Download is free here and you are invited to provide feedback, comments, suggestions and dialogue !

This posting is provided "AS IS" with no warranties.

Wednesday, October 8, 2014

[OpsMgr 2012][OpsMgr 2012 R2] SCOM 2012: Overview link blog by Dieter Wijckmans

Dieter Wijckmans has posted a very good article that give a lot of links to understand SCOM 2012 infrastructure, Design and installation and much more ! :)



If you feel there are things missing or you’ve found dead links please do not hesitate to leave a comment and I will update this post.

Thanks Dieter for this overview !

This posting is provided "AS IS" with no warranties.

Thursday, June 26, 2014

[SCOM 2012] Maintenance Mode Scheduler V3 from Tim McFadden ( #MaintenanceMode #SCOM2012 )

Tim McFadden has released the SCOM 2012 Maintenance Mode Scheduler Version 3 on his blog post here.

http://www.scom2k7.com/scom-2012-maintenance-mode-scheduler-v3/


Here are the new features in V3 that will help address this problem:

  • Schedule Subscriptions for maintenance mode.  Most organizations only use the alerts from SCOM.  Now you can schedule your complex subscriptions into maintenance mode.  You can choose to send the alerts that were queued up or discard them.
  • International Date format of DD/MM/YYYY now supported
  • New Integrated Dashboard with the help of Tao Yang
  • Removed resource pools from the list of groups
  • Changed default start time to only 2 minutes ahead instead of 5
  • Check to verify start time hasn’t already passed
  • Minor bug fixes
    Download a free trial version on the post.
 

This posting is provided "AS IS" with no warranties.

Friday, June 20, 2014

[SCOM 2012][Powershell] Closing all alerts from a specific Management Pack ( #SCOM2012 #Powershell )

I 've today a need to close all alert that has been raised by a  specific Management Pack. The way I decided to work is to list all alerts, detect from what monitor or rule the alert is comming from and then, check the monitor / rule property to know if it's related to the MP I want to close all alerts.


 For using the script, just replace the MY.MP.TEST by you MP name.



  1. # Set variable with the MP name you want to close all alerts
  2. $MPtoCheck = 'MY.MP.TEST'
  3. # Check Open alerts
  4.  $OpenAlerts = get-SCOMalert
  5. # Create an empty list of AlertID
  6.  $ListAlertIDtoClose = ""
  7. #Check what MP has raised the alert
  8.  foreach ($alert in $OpenAlerts)
  9.       {
  10.       $AlertMP = ""
  11.       $AlertID = $alert.ID
  12.       write-host $AlertID
  13.       If ($alert.IsMonitorAlert -eq "True")
  14.          {
  15.          $AlertMP = (get-SCOMmonitor -ID $Alert.MonitoringRuleID).GetManagementPack().name
  16.          }
  17.      else
  18.         {
  19.         $AlertMP = (get-SCOMrule -ID $Alert.MonitoringRuleID).GetManagementPack().name
  20.         }
  21.     
  22.      If ($AlertMP -match $MPtoCheck) {
  23.         write-host "AlertId: " $AlertID "is from " $AlertMP " and must be closed." -foregroundcolor "red"
  24.         if ($ListAlertIDtoClose -eq "")
  25.            { $ListAlertIDtoClose = $AlertID.guid }
  26.         else
  27.            { $ListAlertIDtoClose = $ListAlertIDtoClose + "," + $AlertID.guid}
  28.       } 
  29.   }
  30. # Show the list of alert ID that must be closed
  31.  $ListAlertIDtoClose
  32. # Create a table
  33.  $ListAlertIDtoCloseTable = $ListAlertIDtoClose.split(",")
  34. # Close all alert from the table
  35.  foreach ($AlertID in $ListAlertIDtoCloseTable)
  36.     {
  37.      get-SCOMAlert | where {$_.ID -like $AlertID} | Resolve-SCOMAlert -Comment "All alerts are closed by powershell script."  | out-null
  38.     }

Note :


For testing purpose, I've just removed the "| Resolve-SCOMAlert -Comment "All alerts are closed by powershell script."  | out-null " in line 37. For each Alert ID in the table, it will only show the alerts and not close them.

So in the screenshot, you can see lines in red - they are corresponding to alerts ID that are raised by MY.MP.TEST
Then in the middle, you can see a list of ID coma separated, this is the line 31 that is executed.

The table at the end, is listed all the alert from the list. since I removed the  "| Resolve-SCOMAlert -Comment "All alerts are closed by powershell script."  | out-null " in line 37, alerts are not closed.



Be carefull when closing alerts - this should be used in a test environnement first !

This posting is provided "AS IS" with no warranties.

Monday, January 21, 2013

[OpsMgr 2012] Patience is a virtue with the System Center 2012 Operations Manager SP1 installation

Published on 2013, January the 16 by  this article is very interesting and please read it before installing SP1 on your SCOM 2012 infrastructure. 


Now that System Center 2012 Service Pack 1 is released, you need to take care when applying this to your Operations Manager servers. As part of the Service Pack installation we make some changes to the OperationsManager database objects, adding additional indexes, etc... As all the management servers share the same database, these changes only need to be made when installing the Service Pack on the very first server you install to. When you run the Service Pack 1 installation it communicates with the database to determine if this is the first installation, and then decides if it needs to run a SQL update script or not.

This means that you need to be patient with your installation and wait for the first management server to have Service Pack 1 installed before beginning the next installation. If you don’t then the SQL script will run again and issues may occur. It is very early on in the Service Pack installation process that the management server checks to see if the DB has already been upgraded, so do not be tempted to tee up your other management servers and run through the initial wizard while you wait for the first server to install because by then it will be too late.

Read the full article directly on technet.

This posting is provided "AS IS" with no warranties.