Targets need to be carefully selected for everything from overrides, to creating new monitors and discoveries. In my experience, this is one of the most difficult concepts to grasp. A crash course in object-oriented programming (OOP) concepts is a great primer to understanding the service model framework in SCOM.
Understanding classes and how inheritance works is essential in selecting or creating targets. Every class may have one or more instances, and each class may be typed (or specialized). When an class is typed, it can be considered a concrete class in SCOM. Concrete classes are typically the best target for monitoring.
For example, Windows Computer is not considered a concrete class, and in most cases should not be targeted for monitoring. See this article for an example of how the Windows Computer class is typed.
Windows Computer is typed because there are several different versions, and each version may have different or additional monitoring requirements. Typing allows the developer to easily implement these monitoring differences, and also allows the administrator to select the correct type for new monitoring or overrides.
Here are some general rules for targeting:
- Target the most derived class (typed class) for new rules and monitors
- Avoid targeting Windows Computer for monitors* (see below)
- Target new rules to Windows Computer only if it applies to all versions of Windows
- Avoid creating new rules or monitors in a disabled state, only to enable for a group* (see below)
- If there is not a good target a new monitor, then create a new class and discovery
*The first best practice in this series:
Avoid creating monitors in a disabled state and target Windows Computer. There are very specific situations that call for any monitor to be disabled by default. Not having a valid target is not a reason – this indicates the need to create a new class.
Selecting Window Computer for new monitors will distribute that pack to every Windows instance in the environment. This in itself is not a detrimental problem – but if the monitor is disabled by default, the result is an empty white circle in the Operations Console and this is confusing to operators.
Imagine if this was a regular practice – Health Explorer could eventually turn into a list of empty white circles and monitors that do not apply to that instance.
Understanding targeting is a preface to service models, which is the framework for application health rollup. Omitting the service model will inhibit the ability to create useful dashboards in the future.
If you have a particular subject you’d like me to talk about, or to call me out on anything I write, send me a message at https://projects.scomskills.com/messenger/suggestion.