Friday, March 15, 2013

Management Packs: The Pain & The Glory

When looking at SCOM, no matter what version, it’s the Management Packs (MPs) what’s make it tick. Simply because without any additional MPs, no monitoring – except for SCOM itself - will happen. So SCOM delivers the framework for the monitoring and the MPs deliver the monitoring functionality.

And as we all know, the quality of the MPs differs. A lot. Some MPs are really good and shiny examples where as others aren’t that good or outright bad and bring down the overall monitoring experience.

And yes, I am singing this song for quite a few years now, even before I became a MVP. Being a MVP brings many advances (thank you Microsoft). One of those advantages is that you get to know some of the people behind those very same MPs. Which makes it harder to criticize those MPs because before you know it, it may become a personal thing. But that’s the least thing I want to start. No bashing, nor flaming or criticizing people on my blog. My intensions are to make a product better by delivering objective criticism, aimed at the products and not at the persons involved.

My Top Ten of my MP personal wish list
Working with SCOM and all it’s iterations and many MPs (from Microsoft and many third parties) I have built myself a personal wish list about how a MP should look like and more important, function. This my Top Ten:

  1. MPs should be divided in to different building blocks:
    1. Library MP;
    2. Discovery MP;
    3. Monitoring MP;
    4. Presentation MP;
    5. Reporting MP;
  2. For Item 1: Per product version only items 1.2 and 1.3 should be different and limited to that version only. So the dependencies should be right and not become a spaghetti.
  3. Every MP should contain good and usable Reports;
  4. Every MP should have a two guides:
    1. A quick start guide (to get you up and running fast);
    2. A comprehensive guide covering all aspects, also ALL Rules, Monitors, Discoveries and so on.
  5. Every MP should have many (or even all) Discoveries disabled, enabling a phased roll-out with:
    1. Two to three override MPs, enabling some or more overrides;
    2. Discovery Helpers, like the ones present in the Exchange 2007 MP.
  6. All MPs should adhere to a standard of monitoring, reporting, dashboards and presentation;
  7. All MPs should adhere to a standard naming convention;
  8. All MPs should be configurable by using a Wizard driven interface, asking questions and creating the correct override MP at the end;
  9. All MPs should be configurable by using the same Wizard as stated in Item 8;
  10. All MPs should use the same approach for monitoring, alert handling. So expeditions like the Correlation Engine are a no-go OR should become standard for ALL MPs.

Three other things which are important:

  1. All MPs should come out OK when run against Management Pack Best Practices Analyzer (MPBA). When not, the MP should be fixed before being published;
  2. All MPs should be tested thoroughly in serious production environment before being published;
  3. All Microsoft products MUST be covered by MPs adhering to the Top Ten MP wish list.

This will make the MPs better and SCOM as well. I wonder what your thoughts/ideas are about this topic. Please feel free to share.

5 comments:

Stanislav Zhelyazkov said...

MP for a product should be released at maximum 3 months after the official release of a product.

Tom Riddle said...

Would be great if they gave greater control on how MPs get deployed. Perhaps there could be a group-based targeting system with a default group as the main targeting.

John Bradshaw said...

You are correct Marnix. The standard of the Microsoft MPs is all over the place. It would be much, much better if a published standard could be adhered to. Things like spelling mistakes etc, are evidence of sloppy Quality Control.

Anonymous said...

I would like to know why should I separate my MPs in multiple files. ?

Thanks

Jimmy

Marnix Wolf said...

Hi Jimmy.

Good question! When creating a basic MP directly from the OM12 Console itself, this approach isn't required.

But when Authoring MPs in VS with the Authoring Extensions, this approach is required.

This way it's easier to differentiate between functionality (discovering, monitoring, reports for instance). This enables easier maintenance and better versioning as well. Not only for the version of the MP itself but also for the versions of the related products it monitors.

Cheers,
Marnix