And Ruben is back at it again! This time he has rather interesting topic, that is always hot for a SCOM admin – tuning your management packs! Out-of-the-box, SCOM creates a lot of alerts. I mean A LOT. Truthfully, not every one of those alerts is useful, or relevant to you. If you just let it be like that, you or your support teams would waste a lot of time working on unnecessary alerts instead of focusing on the ones that actually matter. That is why tuning any management pack you import must be tuned to only focus on the things that matter to you and your organization.
That is exactly what Ruben has come up with here. I’m sure this information will be critical for any SCOM admin. Here goes:
SCOM Management Pack tuning step by step
This post explains Management Pack tuning, the reasons why it is required and how it can be performed with the help of free tools and PowerShell.
Monitoring Console showing Alerts
Every Management Pack contains rules and monitors to indicate a potential issue or expose an already existing problem. Another common type of rules are used to collect performance data.
The Management Pack author or the vendor decide which rules and monitors are enabled by default and which can be enabled via overrides from the SCOM Administrator.
Every environment is different so the judgement which rule or monitor is useful are not the same.
It is the best practice to disable all rules and monitors that don’t bring obvious benefit.
On the other hand, there might be rules and monitors that could be useful for you so you should enable them. The process of doing this is called ‘Management Pack tuning’.
For a few reasons it is important to Management Pack tuning immediately after importing.
- Alerts that don’t have a noticeable impact just distract SCOM Administrators or Operators.
- Performance data that is recorded but not analyzed consumes resources on the Database and makes SCOM significantly slower.
- The more rules and monitors are active on the monitored computer the busier it is handling ‘monitoring’.
A nice side effect is that you’re doing documentation by doing so. It is easy to tell someone what is monitored and what not.
Invite subject matter experts to do the Management Pack tuning with you together.
This gives three direct benefits.
- The experts, e.g. DBAs know what is monitored
- The experts will tell you what it is needed from their perspective
- You, the SCOM Admin can share the responsibility when it comes to the question ‘why did we not know about it before?’ or ‘why wasn’t there an alarm?’
Performing the tuning
As example we will use the Management Pack for the Windows Server 2008.
Note: Usually you only need to care about Management Pack files named monitoring. – Leave those called discovery untouched. Smaller Management Packs might just consist of a single file.
- Download the Management Pack Windows Server Operating System and run the setup.
Keep the default location
C:\Program Files (x86)\System Center Management Packs\SC Management Pack for Windows Server Operating System
- Download MPViewer from https://github.com/JanVanMeirvenne/mpviewer
- Copy the PowerShell script from https://gist.github.com/Juanito99/ae7f1ec364ec55bfeb316c3e029d20b2 into PowerShell ISE or VSCode and name it MPTuining-RulesAndUnitMonitors.ps1
- The script requires PowerShell v3 at minimum. – It is given by Windows Server 2012 by default, for older Windows Server versions please install the current Windows PowerShell version (at the day of writing it is PowerShell 5.1)
- Store everything on a Management Server (E.g. C:\Temp\MPTuning).
- Create a new Override Management Pack for that specific MP and name it properly.
Administration Pane to create a Management Pack
Naming the Management Pack properly
- Launch exe and load the Management Pack named Microsoft.Windows.Server.2008.Monitoring.mp from the default location and choose “Save to Excel”.
Management Pack Viewer
- Name the file WindowsServer2008MonitoringExport for instance.
- Open Microsoft Excel and open the file, select the Monitors – Unit sheet and hide all columns except of A, D, H and O
- In the Ribbon bar select Data and add a Filter. For column D choose only Enabled Monitors. Review and decide if they should be kept enabled. – From my perspective all are useful.
Excel sheet Monitors Unit showing filtered columns
- Revert the selection so that Enabled is set to False. Review. I left them also as they are.
- Switch to the Rules sheet and limit visible columns to A, C, D, K and O. Afterwards set the filter to show Enabled: True and Category: PerformanceCollection.
Excel sheet Rules showing filtered columns
- Copy rules that seem to be not useful into a text file and name it txt
Text file WindowsServerManagementPack2008_RulesToBeDisable.txt
- Note down the name of the Windows Server 2008 Monitoring Management Pack and the Override Management Pack.
Administration Pane showing Windows Server MP Name
- Navigate to C:\Temp\MPTuning and open the PowerShell script MPTuining-RulesAndUnitMonitors.ps1 (with VSCode for example)
- Place the file txt needs to be there, too.
VSCode running script
- Place the file txt needs to be there, too.
|sourceManagementPackDisplayName||‘Windows Server 2009 Operating System (Monitoring)’||Management Pack that contains the rules and unit-monitors we will override|
|overrideManagementPackDisplayName||‘ABC.Windows.Server.Overrides’||Management Pack we created to store the our configuration changes (overrides)|
|itemType||rule||Sets that we will change rules|
|itemsToBeEnabled||False||Rules will be disabled|
|inputFilePath||WindowsServerManagementPack2008_RulesToBeDisabled||Name of the file that contains the rule names we specfied|
- Run the PowerShell script by hitting ‘Enter’
- After a short while the overrides will appear in the Management Console
Authoring Pane Showing Overrides
- Repeat the procedure for rules that you like to enable.
If you experience problems or have other questions, come to join our SCOM community at https://gitter.im/SCOM-Community/Lobby
You can know more about Ruben here:
Ruben Zimmermann (A fantastic person who has a lot of great ideas) [Interview]
More from Ruben:
Guest Blog – Authoring a PowerShell Agent Task in XML – By Ruben Zimmermann