SCOM Tuning Tips

Here are some SCOM tuning tips that I published back in 2012 that are just as relevant today as they were back then. This was taken from a SCOM support guide that I created for a large insurance company.

Reasons why we create new MP rules and monitors:

1. To generate new monitoring that was not provided in the vendor packs
2. To replace a vendor developed conditions that lacked sufficient overrides
3. To setup a scheduled script, gather reporting data, or an administrative auto action
4. To gather data for possible future alerting solution

Reasons why we recreate MP rules and monitors:

1. To expose settings not available in the sealed overrides
2. To replace poorly worded alert messages names or descriptions
3. To add a repeat count, recovery, or other method to reduce alerts or to reduce frequency
4. To consolidate multiple alerts for the same issue
5. To consolidate alerts with the same troubleshooting steps
6. To reduce alerts during maintenance, software updates, backups, network outages, and other factors
7. To convert a rule to a monitor or vice versa to access available functionality

Reasons why we “disable” conditions ( or make alerts informational):

1. We disable all warning or critical level alerts that are informational or successful in nature (reserving alerts for things that are broken)
2. We disable application monitoring that duplicates base server monitoring (hardware, OS, custom)
3. We disable all monitoring that doesn’t relate to actionable troubleshooting steps (if we can’t fix it we don’t want to see it)
4. We disable a lot of external dependency monitoring. For example, Exchange alerts on AD availability that duplicates monitoring from the AD MP)
5. We disable any problematic alerting conditions that do not work properly (identified by experience or community feedback)
6. We disable any alerts that are determined not to be a real issue in our environment; or any environment. (For example, important sounding alerts that cannot be linked to a problem requiring intervention)

Reason why we implement overrides:

1. To modify the priority or severity to meet our alerting needs
2. To disable or enable rules, monitors, or discoveries (for effect or replacement)
3. To modify thresholds and other setting on rules, monitors, or discoveries
4. To limit alering activity to a specific group of objects (or exclude)

Overrides that don’t appear to be possible or are rarely available:

1. Modify the alert name and description
2. Modify the custom fields and alert suppression criteria
3. Ability to add recoveries and diagnostics to sealed rules and monitors
4. The ability to add views to sealed management packs as an override
5. Common overrides are often not available like priority and severity