Best practices and recommendations to create Management Packs

Best practices and recommendations to create Management Packs

Spread the love

Hi all. Today I am going to write about best practices and recommendations. A lot of the recommendations are from my own experience and years of testing the best way to do it most simple as it possible.

I make to you a few question to know if this post is for you or not.

¿Do you have management packs sorted by version? ¿Does the version of the management packs reflect every change made in it?Do you keep up-to-date the knowledge base of the management pack with date of update, version of the previous Management pack to be able to identify changes and failures?, ¿Can you change any settings you want without creating a new Management Pack?, ¿Do you have a ton of alerts?, ¿Can you know with a quick view in the console what you have configured?

If the answer to one or more of these questions is no, continue reading and make a couple of changes together!.

Best practices and recommendations

Management Packs

As you know, the Management Packs are the core solutions of SCOM, we should take care of a few things:

  • Keep a good repository of Management Pack.
    • It’s so simple, that nobody does it. A good repository should have the default Management Pack with their .msi file and the custom Management Pack sorted by Product > Type (Custom or default) > Version >MP files, installer and documentation. If you do that, is going to be really more easy to you to make a roll back if something fails, have a control of the changes, have the installers files in case of a migration, audit changes.

  • Each default Management Pack should have custom Management Pack.
    • When we download a Management Pack from Microsoft or we sealed a custom one, this management pack lost the capability to be editable, and on the other hand, not all the time the Microsoft Management Pack have the monitor options enable as we need. So, each time you download a Management Pack, create a custom one and maintain the version changes.
  • Version and knowledge base of the Management Pack.
    • Every time you edit your Management Packs you should change the version of the Management Packs. By default when you create a Management Pack it start with version 1.0.0.0, if you save it and then you change something else you should do three more changes:
      • Before making any changes if the version 1.0.0.0 was not exported, export it and save the Management in your repository.
      • Make all the changes you need and change the version of the Management Pack from 1.0.0.0 to 1.0.0.1.
      • Create a knowledge base with the changes and all the information that you believe important for the person who will come after you. (When you do it, what you do, does the change have an associated ticket? put it there) Finally, save the changes and export the new Management Pack to the repository.

Overrides

By default, for example, the SQL Management pack for SCOM have a few a discoveries/rules/monitors that for sure you will want to have and another one that you would like to disable, as for example the SQL Jobs discovery in the SQL Management Pack. This part is really easy, but we have to follow a few steps and I will explain my own experience and recommendations in a few rules that I follow.

Notes: These are the rules that I follow, they are not the absolute truth nor the only way to do it.

  • Rule 1: Every default Management Pack should have a custom Management Pack. This is because the default Management Packs are sealed and we can not make changes in it.
  • Rule 2: The custom Management Pack will contain all the changes that you made and you should disable everything that you are not going to use. If you don’t disable the alerts that you don’t need you will have 2 issues: Performance of SCOM will be affected and you will have a ton of alerts that nobody care about.
  • Rule 3: Use dynamic groups contained in the Management Pack custom. If you work with specific customers you can create a Dynamic group following specific criteria or specific information contained in the agents and this way the targeting of the overrides is going to be really easier
  • Rule 4: Disable for all, enable for a few. If you follow the rule 3 you would say “Hey but I want to monitor a specific service in a specific server, I don’t want to push this change in all the servers”, and here is where we are going to apply the Rule 2. The best practices should be: Disable the alert/monitor/rule to all the class of > Enable the alert to a specific object. As one day a Microsoft guy told me “It only cares the more detailed and specific configuration that you can configure“.
  • Rule 5: Test, break, try again, fail again until you get it, but always document what you do, to erase what you did wrong and thus have a clean infrastructure.

I hope these recommendations will help you in the future with a better and more orderly platform. Do not hesitate to ask me any questions.

Regards.

Recommendation: How to create a custom Management Pack and make an override

Leave a Reply

Your email address will not be published. Required fields are marked *