locked
Management Packs Beginners RRS feed

  • Question

  • We have deployed SCOM 2012 CU2 recently and I am still confused about strategy about Groups , management packs etc.

    What is your thought on:

    How many custom management packs should we have (I checked and found we should create a custom one for each imported MP)

    Shall we create all monitors / rules in disabled state targeted to Windows Server Class and then override them to the Groups  (is this the best practice)

    Where should those group be saved in (Which management pack)

    The confusion is when we try to target the monitor/rule etc we can reference the unsealed MP's

    Is it create a Custom MP and save All monitors,rules ,groups to this Custom MP. So that referencing each other is not an issue.

    Will this cause the MP to bloat or crash if we save everything in it.

    I dont even know how to ask this question.

    All i want is to make it simple while creating Monitors , rules , views , dashboards , reports.

    Thursday, December 20, 2012 12:51 PM

Answers

  • Thanks for the information I have now adopted a standard in my documentation/usage based on the replies when working with overrides.

    My question is now what about MP usage when creating monitors, rules and tasks. Would you create one management pack for each of these or again point them in the previously created overrides for certain management packs?

    It is best that you make a distinction between rules and monitors for different purposes and centralize the different rules and monitors for a purpose in 1 management pack.

    For example if you want to monitor Unexpected reboots.

    You name your unsealed management pack: Company name_custom_unexpected reboots and save your monitors related to this field of monitoring in this management pack.

    Again it is better to create more unsealed management packs (and target them properly) than create 1 big one because if the big one gets corrupted or has some dependencies to a management pack you would like to delete you will have a problem.

    That's also the reason why you should never safe any overrides / rules / monitors / views to the default management pack.

    Bottom line: Create a unsealed management pack for all different fields of monitoring + overrides.

    Last but not least: backup your unsealed management packs automatically by implementing an export: http://kevingreeneitblog.blogspot.be/2012/02/scom-2012-quick-script-to-backup-your.html


    It's doing common things uncommonly well that brings succes.

    • Marked as answer by Cloud_TS Tuesday, January 1, 2013 9:08 AM
    Monday, December 24, 2012 3:27 PM
  • A couple more things to bear in mind:

    - you can't reference an unsealed management pack from another unsealed management pack.

    - if you deploy Service Manager 2012 (another component of the System Center 2012 suite) then you can also import management packs so that you can track your SCOM objects to incidents and changes. But ideally, you should only import sealed MPs to Service Manager.

    With that in mind, you might want to start thinking about a process for sealing your custom monitoring management packs where you are creating:

    - the base classes (this MP could then be Sync'd with Service Manager) in one MP

    - the monitoring (rules \ monitors) in another MP

    and then having an unsealed management pack for the overrides.


    Regards Graham New System Center 2012 Blog! - http://www.systemcentersolutions.co.uk
    View OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/

    • Marked as answer by Cloud_TS Tuesday, January 1, 2013 9:08 AM
    Monday, December 24, 2012 4:11 PM

All replies

  • Hi kitaab,

    I sense you are struggling with the custom management packs design.

    A couple of answers to your questions:

    1. It is best practice to create an unsealed management pack for all management packs you import to store the overrides. Make up a naming convention that is suitable for you: Companyname_originalmpname for example.
    2. If you want to scope a rule to just a group of servers it is indeed best practice to use a class which is common for all the servers of that group (windows server class, sql server class,...) and create the rule disabled and enable it for a specific group through overrides.
    3. The catch is in fact as you already mention that you can't reference groups of other unsealed management packs but only from the sealed management packs. So if you want to apply the rule to a specific group the group needs to be made in the same unsealed management pack as where you have created the rules / monitors in.
    4. It is best practice to keep an unsealed mp for all other sealed mp's and not work with 1 big unsealed mp. It will work but you will face issues when there's corruption of the management pack or when you need to delete a sealed management pack that has references to this unsealed mp.

    A couple of helpful links:

    http://scug.be/dieter/2011/06/20/scom-2007-target-a-rule-or-monitor-to-a-computer-group/

    http://blogs.technet.com/b/jeanie_d/archive/2011/07/28/groupsmp.aspx

    If you need more info please do not hesitate to ask.


    It's doing common things uncommonly well that brings succes.

    Thursday, December 20, 2012 3:24 PM
  • >How many custom management packs should we have (I checked and found we should create a custom one for each imported MP)

    If you're asking about custom MP for overrides - as a best practice you should have one custom MP for every sealed MP. 

    >Shall we create all monitors / rules in disabled state targeted to Windows Server Class and then override them to the Groups  (is this the best practice)

    No. You need to select a proper targets (classes) for your monitors instead. Or create your own classes.

    >Where should those group be saved in (Which management pack)

    It depends. I am always create groups in a corresponding MP (custom SQL groups in a custom SQL MP, custom Hyper-V groups in a custom Hyper-V MP etc) or in a dedicated MP like a 'Company - Groups - Hyper-V'.

    >The confusion is when we try to target the monitor/rule etc we can reference the unsealed MP's

    You can seal your MPs. It's easy and definitely a good idea.

    >Will this cause the MP to bloat or crash if we save everything in it.

    Generally speaking, No, it will not cause a crash. But you'll get a big headache if you'll need to delete a sealed MP that is referred by some override in this big MP. Or if you have a big management group and this MP will go over the network to ALL your agents.

    >All i want is to make it simple while creating Monitors , rules , views , dashboards , reports.

    Sometimes 'simple' is the worst enemy of a 'good'. Learn authoring (using an authoring tools like a VSAE or 2007 Authoring Console, not the Operating Console). It will help you a lot. Authoring is a best way to a good understanding of OpsMgr internals. 


    http://OpsMgr.ru/

    • Proposed as answer by Alexis Yakovlev Thursday, December 20, 2012 7:06 PM
    Thursday, December 20, 2012 4:26 PM
  • Hi, just to throw a question in also. I am new to SCOM - one month - and would like to tidy the situation I find our management packs. Would you really create a MP for EVERY sealed MP if you have say 100? Or just say one to cover all "2008 server" for instance if there are 3 for that for example? Thanks
    Thursday, December 20, 2012 5:35 PM
  • >Would you really create a MP for EVERY sealed MP if you have say 100?

    You only need to create it when you're create an override for a workflow stored in a sealed management pack. You don't have to pre-create an empty unsealed MP for every sealed MP. So this process won't be labor-intensive or time consuming.

    > Or just say one to cover all "2008 server" for instance if there are 3 for that for example?

    You can go this way but I prefer a 1:1 ratio.


    http://OpsMgr.ru/

    Thursday, December 20, 2012 5:49 PM
  • you will not need an override MP for EVERY sealed mp. some MPs you will never need overrides for. Yes stick to a naming standard, and here is what I've used for a while, Sealed MP Name - Override 

    Example:

    Windows Server 2008 Operating System (Monitoring)

    the override mp would be named :

    Windows Server 2008 Operating System (Monitoring) – Overrides

    This will make it easier to find if you have an Overrides MP when viewing them in the MP View.
    Hope this helps!


    Scott Moss MVP (Operations Manager) President - System Center Virtual Users Group |Vice President - Atlanta Southeast Management Users Group (ATL SMUG)
    Please remember to click “Mark as Answer” on the post that helps you!
    my new blog om2012.wordpress.com

    Friday, December 21, 2012 4:47 AM
  • Thanks for the information I have now adopted a standard in my documentation/usage based on the replies when working with overrides.

    My question is now what about MP usage when creating monitors, rules and tasks. Would you create one management pack for each of these or again point them in the previously created overrides for certain management packs?

    Monday, December 24, 2012 1:26 PM
  • Thanks for the information I have now adopted a standard in my documentation/usage based on the replies when working with overrides.

    My question is now what about MP usage when creating monitors, rules and tasks. Would you create one management pack for each of these or again point them in the previously created overrides for certain management packs?

    It is best that you make a distinction between rules and monitors for different purposes and centralize the different rules and monitors for a purpose in 1 management pack.

    For example if you want to monitor Unexpected reboots.

    You name your unsealed management pack: Company name_custom_unexpected reboots and save your monitors related to this field of monitoring in this management pack.

    Again it is better to create more unsealed management packs (and target them properly) than create 1 big one because if the big one gets corrupted or has some dependencies to a management pack you would like to delete you will have a problem.

    That's also the reason why you should never safe any overrides / rules / monitors / views to the default management pack.

    Bottom line: Create a unsealed management pack for all different fields of monitoring + overrides.

    Last but not least: backup your unsealed management packs automatically by implementing an export: http://kevingreeneitblog.blogspot.be/2012/02/scom-2012-quick-script-to-backup-your.html


    It's doing common things uncommonly well that brings succes.

    • Marked as answer by Cloud_TS Tuesday, January 1, 2013 9:08 AM
    Monday, December 24, 2012 3:27 PM
  • A couple more things to bear in mind:

    - you can't reference an unsealed management pack from another unsealed management pack.

    - if you deploy Service Manager 2012 (another component of the System Center 2012 suite) then you can also import management packs so that you can track your SCOM objects to incidents and changes. But ideally, you should only import sealed MPs to Service Manager.

    With that in mind, you might want to start thinking about a process for sealing your custom monitoring management packs where you are creating:

    - the base classes (this MP could then be Sync'd with Service Manager) in one MP

    - the monitoring (rules \ monitors) in another MP

    and then having an unsealed management pack for the overrides.


    Regards Graham New System Center 2012 Blog! - http://www.systemcentersolutions.co.uk
    View OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/

    • Marked as answer by Cloud_TS Tuesday, January 1, 2013 9:08 AM
    Monday, December 24, 2012 4:11 PM