[OpsMgr 2012] The Add Object Wizard in Operations Manager 2012 displays only 500 objects even if more than 500 exist ( #OpsMgr2012 )

When you use the Add Groups or Add Object button while creating a report in Microsoft System Center 2012 Operations Manager (OpsMgr 2012), no more than 500 objects are displayed in the Add Object Wizard even if more than 500 exist.

This default limit of 500 objects is by design, and this setting is controlled through the system registry.
Microsoft has published on 2014 June the 24th,  KB2976809 to provide a way to increase  the maximum object limit in the Add Object Wizard.

Link to KB2976809

To work around this issue, create a registry key to manually set the maximum object limit in the Add Object Wizard.

To do this, follow these steps:

1. On the computer that's hosting the Operations Manager console, close all running instances of the console.
2. Start Registry Editor. Make sure that you're using the same user account that's used to run the console.
3. Locate and then click the following registry subkey: HKEY_CURRENT_USER\Software\Microsoft\Microsoft Operations Manager\3.0\Console
4. Create a new DWORD value key, and save it as MaximumSearchItemLimit. Assign a value to this key that reflects the maximum number of objects that you want to display. For example, use a value of 1000 if you want to limit the maximum number of objects to 1000 instead of to the default limit of 500.

Location: HKEY_CURRENT_USER\Software\Microsoft\Microsoft Operations Manager\3.0\Console

Name: MaximumSearchItemLimit

Type: REG_DWORD

Value: 0 to 65535

 

Then Exit Registry Editor.

 

To verify the new setting, start the Operations Manager console, and then open a report that uses the Add Group or Add Object button. Click the Search button in the Add Object dialog box, and then verify that the maximum number of available items that are now displayed matches the MaximumSearchItemLimit value.

Note Make sure that you repeat steps 1–5 on all computers that are hosting the Operations Manager console.

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

[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.

Direct link to the post

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.

[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.