Best Practices – Targeting Introduction

UPDATED 03/15/2015

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

13 thoughts on “Best Practices – Targeting Introduction”

  1. Good article. However, I am not sure I would say “never” target windows computer with disabled monitors. I agree, seeing empty monitors in the health explorer is annoying. Also, putting down a placeholder that is not used, can’t be great for the instance space, especially in large environments. Having said that, there are certain situations where, having monitors, maybe aggressive monitors, deployed but not enabled could be helpful to identify issues on problematic machines. Yes we can use perfmon, powershell, etc., but if we have a handful of monitors that operations teams could use at the time of an issue, turn them on with overrides for a few boxes, I think there might be some value in that. You and I have talked about this before, the pros and cons of doing something like this in SCOM, and at the time I think we both agreed perfmon was the way to go. However, you also know that sometimes, the powers that be, don’t want to know what is the best practice, and instead override your decision. The only other thing I will add to this is that I don’t know many operators who actually use the health explorer. Our organization still uses SCOM primarily as email notification machine, state changes are orphaned (thanks to clusters, and poorly written monitors) and the health explorer, especially on Exchange 2010 server, is longer than an Eadar Allan Poe tome, rendering what information it provides you utterly useless. Even in SCOM 2012, I don’t see much value in the “health explorer”. Also when is MSFT going to start bringing knowledge back into their management packs? The hyperlink junkyard (this link is no longer valid etc), while I understand the reasoning behind it, is no where near as useful as how it was before with knowledge written in the actual knowledge tab… I digress

  2. Hey Blake – good to hear from you!

    Windows computer is intended to be a base class, not a monitoring target – but this is just one example.

    Beyond that even, here’s how I look at it:

    Custom packs should not have monitors disabled by default, regardless of the class it is targeting. There is always an operational need to develop a new monitor, so why would it be disabled by default? The only reason I’ve seen, outside of vendor packs (which is a different story), is because developing a service model takes a little more time and effort. This shouldn’t be an excuse – and this is how systems gradually become more and more unmanageable over a period of time.

    I’m going to expand more on this topic in the future. Looking forward to your comments on those articles. 😉

    1. Groups. Any rules or monitors that need to applied to groups should be disabled and then an override created.

  3. Jonathan – thanks for sharing another great post of best practices. I wish so much information was available over five years ago when I was trying to learn to author.

    Both you and Blake raised some good points, but I have to side with Blake on using the word “never”. Some situations simply make it unavoidable. We don’t typically target ‘Windows Computer’ so much as ‘Windows Server’, but, to me, these are one and the same since we do not monitor clients. I’m not a fan of using that practice, but, again, sometimes it is unavoidable. However, one thing you do need to be careful about is targeting overly specific – to the point that you end up with a lot of dependencies that you probably should not have. I’ve run into issues where we’ve had to remove what I would call a core MP (not a MS MP, but core to our environment) because of broken upgradeability and ended up with the task of removing a lot more monitoring because of the dependencies that were created.

    Regarding disabling monitors and rules by default – we have run across many 3rd party applications that incorporate complex failover and a criss-crossing web of roles across multiple servers, all while the vendor refused to provide a SCOM management pack. Since we end up having to create custom monitoring for these situations, we have run across situations where some of our own monitoring is disabled by default and then enabled via override for a specific object. The service model is usually correct, but the complexity of roles and failover simply don’t allow for all monitoring to be active at once on all of the discovered objects. Luckily, these are the exception, not the standard.

    Thanks again for sharing such high-quality posts!

  4. Hey Larry, I’m glad you like the articles. I also wish this type of information was out there years ago when I started authoring. There are a lot of “how-to” articles out there, but rarely do they explain why they do certain things – and often times these article demonstrate bad practices.

    I have never run into a situation where I needed to choose Windows Computer for a monitoring target (and this goes for Windows Server as well). I’d like to hear a situation where the only option was to target Windows Computer for monitoring – I’ll bet anyone a dollar I could find a better target 😉

  5. Great posts. SCOM is definitely in need of some best practise. As mentioned in the posts above the default method in the industry is disable the monitor, enable for the group. Lots of empty green bubbles flying around which spoils the health explorer. It always suprised me that Microsoft don’t cover this in the SCOM course. Surely an issue like this which is well known could be fed back to the trainers to educate the community or am I living in some web 2.0 cloud cuckoo land!

  6. I have lots of custom monitoring on a specific server. It is a must to disable to monitor/rule then enable for a specific object, is this true? Is there any alternative?

    1. Amy – the alternative is to discover a type of class for that server (or particular application), and then target monitoring at that class. Even if specific monitors will only run on one server, it is still a good idea to discover an instance of that class.

  7. Thanks for sharing. Nice work! But I do have a question here. We have a seed class which targeting to Windows.Computers. The seed class has few properties such as “AppName”, “LOB” and etc. which are populated via a script discovery. Then we target ALL OF MONITORS to this seed class and disabled by default. There are bunch of groups created per “AppName” attribute. The monitors are enabled per group.
    So this brought up the similar issue as you described here: when open Health Explorer, the operator can see ALL CUSTOM MONITORS in the management group and most of them are with a empty check box.
    I want to improve it here.
    The only way I could think about it is to break down the seed class into few more classes per “AppName”. But the problem is HOW. I know I can populate the new classes via a script discovery too. However that means there will be one discovery per class and we have more than 200 applications. Comparing to the inconvenience when viewing health explorer, getting hundreds of script discoveries would be much worse.
    So the question is, is there any way to break down seed class into few classes per value of seed class without going through a new script discovery?
    I searched on the Internet for days but got no answers. Advise is much appreciated.

    1. blueinjazz – it is not necessary to create a separate script discovery for each class. You can create a single script discovery, targeted at Windows Computer, and have it discover as many different types of classes as you wish. As long as the script has logic to determine which type of instance it should submit as the discovery class, then you can do this with one script for hundreds of applications. You just need to set the correct class instance in the script.


      If (your app = abc) Then
      Set oInst = oDiscoveryData.CreateClassInstance(“$MPElement[Name=’abc’]$”)

  8. I would be curious to know how you handle event monitors. I try to target my rules/monitors as your article suggests, but the one area I have issues with are event log monitors (most of mine are rule based monitors). I tend to target Windows Server Operating System, but the monitor is usually only needed on a small group of servers (2-3), but goes out to all of them. How do you target your event monitors? Do you create a class for each different event log source? Server being monitored? Just curious.

    1. Hi John. Yes – I would create a new class for the type of server being monitored. I’m sure these servers host some particular application, and usually there is going to be a service name or some value in the registry that can be used in the discovery. I also see a lot of folks just going ahead and creating a registry key/value structure purely for the purpose of having a discovery data source. Yeah – it’s another step to managing classes, but it works well, especially if you use SCCM to push the keys, then it’s pretty easy to manage.

Comments welcome (links require moderation)