7+2 Worst Practices for SCOM Management Pack design

If you ever had a chance to squeeze into developers room, you could hear a lot of talks about “best practices”. Seems like everything is covered. Best practices exist for everything: naming conventions and coding patterns, development processes and standup meetings, black-, grey- and white-box testing. Saying nothing about writing specs. Same story for IT – internet is full of advises of any kind. Although all these “best practices” have been created to make life better, I prefer the balanced world. So it is high time to write some “worst practice” notes.

Here is the list of 7 worst practices for SCOM Management Pack design I can think of now:

  1. Multiple objects/counters per performance collection rule;
  2. Using “see ‘alert context’ tab for more details” in alert description;
  3. Not considering Management Pack to be a product/part of the product;
  4. Ignore “corner” cases;
  5. No ways to do historical/retrospective analysis;
  6. Ignore user and user experience;
  7. Too narrow, too wide, too complex, too simple;

Update: I’ve added more worst practices noted by readers and updated the post title. Currently we have 7+2=9 points to discuss.

  1. Discovering properties that are significantly dynamic and at excessively frequent intervals. (Thanks, Craig)
  2. Using eventlogs for determining healthy and unhealthy states unless it is the only option. (Thanks, Craig)


I will discuss all these points in very details in upcoming posts.

And while you’re waiting for updates, enjoy the picture below and don’t forget to leave a comment or tweet me at @oksandbox about other worst practices you know.

SCOM Management Packs Development worst and best practice

8 thoughts on “7+2 Worst Practices for SCOM Management Pack design

  1. 1) Discovering properties that are significantly dynamic and at excessively frequent intervals.
    2) Using eventlogs for determining healthy and unhealthy states unless it is the only option

  2. I’d like to add ‘Active Alert’ views with a criteria of New (0) resolution state ?!? Active alerts are anything but ‘Closed’ (255) . In house MS teams seem to be the biggest culprit with this one.

    • Danny,

      Thanks for comment!

      I took a look at several “Active Alerts” views defined in different Management Packs and all of them used either “not equal 255” or “less than 255” conditions. That means, that those MPs consider “not Closed” alerts to be “Active”.

      Is that a best practice? Is using different condition is the worst practice? I don’t know. I doubt. The reason for my hesitation is that organizations are different and they process alerts in many different ways. Some stick to OpsMgr console, others just forward everything into their favorite ITIL/MOF tool, also there are guys who mix both approaches. I’d rather say that it is a preferred practice, but it really depends on organization’s needs. “Anything but closed” may not work in certain cases.

      • Hi Oleg.
        I was referring views that are only showing alerts with resolution state =0. The actual resolution state or way that an organisation handles alerts is irrelevant. The author of the views in sealed packs should be aware that there are 255 different ‘active’ alert res states, not just ‘New’ !

        Too many of the legacy packs were set to Resolution State = 0 – Office Communication Server 2007R2 being an example. (I should maybe have qualified that MS teams were culprits in the past !) HP seem to also be guilty of this, I can see a folder view called ‘HP Systems’ / Active Alerts with this problem, but on the other hand another folder view called ‘HP Hardware’ / Open Hardware Alerts displaying all alerts not equal to res state 255.

        The inconsistencies could be masking alerts from users who are using the console to monitor / manage their estate..

        • Danny,
          I understand your point. Hiding alerts from users is bad, no doubts. But the question here is: why this was done? What was the reason? For sure, using the “is equal 0” condition without any valid reason is nothing but ignoring the user and her experience and that is a worst practice indeed (#6 in my list :)). However, I assume that someone may use some other definition for the word “Active”. Someone may have another vision of user’s needs. I wish I could have a chat with those guys :).
          As for me, I’m with you on this point, I respect the consistency 😀

  3. Great point! I agree that the “Active Alerts” should always be anything that does not equal 255. In one case I know of, the company has a process which updates custom fields (via a notification subscription executing a command) with server specific info from their CMDB. So that all know it has been processed for the data, the resolution state is changed. Therefore, any views that look for a resolution state of 0 only as active mask over the open alerts. It is for sure a best practice if one wants to consider a “view” an “active alerts” view to leverage anything not equal to 255.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.