Creating your own MP store – Part 1: Fundamental thoughts

  • Article

Foreword:
Recently there have been several blog posts on the topic of creating a personal Management catalog (or store) by Tao Yang, Cameron Fuller and others. I really like their ideas and their creativity. So why do I write about a similar topic? Because I think that these posts do not cover the whole picture and I try to fill this gap a bit.

It sounds pretty simple: Download a Management Pack, import it into your Management Group, configure and tune it and you are ready to go.

Hopefully everybody will agree that understanding the MP functionality, its configuration and its tuning is the complex part of the story, isn’t it? Downloading, extracting and storing the MP is a piece of cake and not worth writing a blog post, right?

Well, in my experience as a field engineer handling MPs is not rocket science, but there are some best practices. This series of blog posts tries to sum up my gained knowledge so far and hopefully gives you some hints on how to handle MPs the most efficient way. And as I am pretty lazy I always like automation, so I will give you some hints for automating MP handling as well.

Intended audience
This blog series is probably not suitable for SCOM admins with a small single Management Group with just a few MPs. Target audience are all SCOM admins with multiple Management Groups (e.g. Development, Test, Integration and Production), most probably not directly connected to the Internet and with lots of custom and vendor specific Management Packs.

Questions I will try to answer in these posts are:

  • Do I really have to store MP files on my file system? 
  • What is the best way to store MP files?
  • What other information besides the MP should I collect and store?
  • Do I have to care about MP Versioning?
  • Where do I find the most current Microsoft MPs and how can I download them most efficiently?
  • How can I build my own personal MP catalog?
  • Is my Management Group using the most current MPs?

This post lay the foundation for the other posts and is purely theoretical. Ok, it is Level 100 but it explains why I handle Management Packs the way I do.

To store or not to store – purpose of storing Management Packs?

Storing MPs in a proper folder structure (call it a store or a catalog) on the file system serves multiple purposes:

  • Having the MP file available for importing into the Management Group
  • Analyzing the MP: What is it doing? How does it work? Does it fit my needs?
  • Comparing MPs: What has changed with the most current version?
  • Using the MP as a reference for creating own sealed MP
  • Using the most current MPs stored in a reference folder as a way of telling if my Management Group is up to date or not

Some purposes might not be self-evident at the moment, but I hope they will after reading the whole series of posts.

Finding 1: It is very useful to create your own MP store or catalog!


What is a Management Pack file?

A Management Pack file can be a file with the extension

  • .MP
    a binary representation of a XML file sealed with a key.
  • .MPB
    Starting with SCOM 2012 we introduced the concept of a MP container or bundle. A MPB file is a bundle of files with at least one sealed XML file with the extension .mpb (like a ZIP container for additional files like images, dlls etc.) or
  • .XML
    a plain, unsealed XML file

Fair enough but in real life, we usually get MPs from vendors not in one of the above mentioned file formats but as

  • a MSI installer file (very common)
  • an EXE installer (ugly and thankfully less common)
  • a ZIP file (uncommon)

So there is not ONE single file format when we get a Management Pack, but multiple.

Finding 2: We are getting Management Packs in different file formats and must be able to handle these formats!


Downloading MP files is not enough

Once we have downloaded the MP in one of the file formats: is it all that we need? Unfortunately not!
Before we import a MP into a Management Group, we probably need some more information:

  • MP guide
    Without a MP guide it will be much more complicated to analyze the MP functionality. Often the MP guide is included in the MSI file, but this is not always the case.
  • Unsealed version of a sealed MP
    Why do I need that? IMHO handling a XML file is much easier than handling a binary MP/MPB file. You can open a XML file with every available Editor quickly, you can compare XML files much better than binary files etc. Therefore I prefer to have an unsealed version of all sealed MPs.
    For own MPs it is also mandatory to have the raw XML available so that you can create new versions easily.
  • MP exports/reports
    Have you ever tried to discuss a MP with a non SCOM guy? Before you import a MP you should get the approval of the Subject Matter Expert of the technology that this MP is worth testing it. Of course you could give him the XML but most probably he won’t understand a line of code. Ok, let’s give him the MP guide. That will work IF there is a guide an IF it is detailed enough. But sometimes it is handy to have an export or a report of all rules and monitors and there frequencies and thresholds available.
  • VSAE or other development tools files
    If you develop your own MPs with Visual Studio and VSAE or with other tools it is handy to store the corresponding project files along with the MP file itself.

Finding 3: We have to store additional information along with the Management Pack file itself.


Keeping the old stuff

Do I have to keep old MP files as soon as a new version is available? Nothing is as old as an outdated MP, right? Hmm, it depends!

  • For own MPs I definitively want to store all previous versions for troubleshooting and change tracking reasons.
  • For vendor MPs (like Microsoft MPs) I also recommend to keep older versions of the MP. In a multi Management Group environment it is quite common, that you will use multiple versions of a MP in different Management Groups. For example you will test the most current version in your Test environment and will use the predecessor in Production.

So my answer is clearly: Yes, I do have to keep old MP file versions! For how long? I don’t know. As I am a hunter and gatherer: probably forever 

Finding 4: It is helpful to keep old versions of all Management Packs we have once installed into our Management Group(s).

How to store MP files in a structured way?

Considering my findings we have to

  • store multiple files for a MP and
  • keep multiple versions of that MP

That sounds pretty easy and straight forward. I also talked about reference folders. What do I mean with that?

  • When you create a sealed MP for a specific Management Group mpseal.exe requires a folder with all MPs that your own MP references. Of course you could create a temporary reference folder on the fly, but believe me: It may take a great deal of time and be a real strain to do that.
    So it is really helpful to have a folder with all MPs currently stored in your specific Management Group available. As your Management Groups might differ you need such a folder for each Group.
  • When you want to verify that your Management Group contains the most current version of all available MPs how do you do that? IMHO it’s a bit tricky and I will explain my solution for that in a subsequent post. This solution is based on a folder with all latest MPs available stored in a separate folder.

Wait, doesn’t that mean to store the same MP multiple times? Yes, that is true!
But we are talking about maybe 1 GB of additional storage and it will definitively simplify your administrative life 

Finding 5: It is helpful to store Management Packs in multiple locations to serve different purposes!

That being said I suggest to store all MP files on a central file share in a folder structure like this:

You will find scripts to create and fill this folder strurture with life in part 3 of this blog series.

What are the benefits of using such a folder structure?

  • Easy to understand
  • It is scalable for as many vendors (Microsoft, HP, Veeam etc.) and as many MPs and versions as you like
  • You can store not only the core .MP file but all other Information as well
  • You can automate the creation of these folders (see next posts)

Finding 6: Create a MP store with a standardized and scalable folder structure.

Why using a folder structure on a file system?
You may ask: Hey Dirk, does Microsoft not provide a better way of storing file versions? SharePoint or TFS perhaps? Yes, we do and if you want, you can use those tools. Tao Yang e.g. has posted a great solution with SharePoint here.
My thoughts and reasons behind using a simple folder structures are:

  • It is simple!!!
  • It is easily transferable between different (walled-off) network zones and you can copy a folder structure on a USB stick if you wish.
  • Not every customer has SharePoint or TFS available
  • Writing automation scripts for a file system is much easier than for automating SjarePoint or TFS.
  • Tools like mpseal.exe are working only with files stored on a file system.

Finding 7: Create the MP store folder structure on a central file share.

Key takeaways

The key takeaways of this post are:

  • It is very useful to create your own MP store/catalog!
  • We are getting Management Packs in different file formats and must be able to handle these formats!
  • It is helpful to keep old versions of all Management Packs we have once installed into our Management Group(s).
  • It is helpful to store Management Packs in multiple locations to serve different purposes.
  • Create a MP store with a standardized and scalable folder structure.
  • Create the MP store folder structure on a central file share.

The next post will talk about how to get the latest Management Packs to fill the store with data.

As always: I would like to hear from you. What do you think about my findings and suggestions?