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.