locked
What ist the best customized Management Packs strategy? RRS feed

  • Question

  • Hi together,

    we plan/deploy SCOM 2016 infrastructure in a large medical organization.

    As you can imagine there are many divisions/derpartments in this organization. Some departments use some applications together.

    We will monitor Windows Computers (first only servers), Linux Computers (first only servers), network components, and some applications.

    The most important are except OS monitoring, also the service monitoring and network monitoring.

    We'd like to monitor mainly

    1) some basic objects for operating systems (CPU, memory, performance, etc.),

    2) some basic services on operationg systems (Windows Update, etc.),

    3) some services of custom applications,

    4) some objects for network components and for medical devices.

    Our targets:

    - We want to define our own sealed Management Packs for above listed monitorings.

    - We want to create separate sealed Management Packs for each department/division.

    - We want to build separate "groups" in SCOM so that objects in each department/division will be sorted/inserted in the related group.

    - We want to make an automatically sorting of the server objects (Windows and Linux) into each group in relation to department/division.

    What is the best customized Management Packs strategy for theses purposes? Or other suggestions?

    Best Regards

    Birdal

    Tuesday, February 21, 2017 3:44 PM

Answers

  • Hi Birdal,

    To "We want to define our own sealed Management Packs for above listed monitorings."

    You can start with unsealed management packs and when you think the configurations there are complete, seal them so that they can be referenced.

    To "We want to create separate sealed Management Packs for each department/division."

    To be honest - I don't like that. It is best practice to store overrides of default management packs in unsealed MPs and have one Unsealed MP per Sealed MP (this is general approach and can vary a bit). If you want further separating this on department basis, this will lead to a handful of MPs, which is not a good approach. In my humble opinion you should reconsider this.

    I would go ahead and store override of sealed MPs in an unsealed MP (you can seal it later) and have one Unsealed MP per Sealed MP and then create MPs for the configurations (Groups, custom configs based on department, etc.) in separate, per department MPs...

    Let me suggest something. Start here:

    System Center Service Manager / Operations Manager Management Pack and Naming Convention Best Practices

    Read it carefully and then re-think your strategy. You will understand why I am asking you this after you finished reading the post. It has lots of real examples in it and they will answer some of your questions. Afterwards you can develop a strategy for the MPs.

    To "We want to make an automatically sorting of the server objects (Windows and Linux) into each group in relation to department/division."

    In SCOM you can create groups with dynamic memberships. This is the way to go in this case.

    You will have to define the criteria for the membership like for example OU in Active Directory. And then create groups with dynamic members. This will require of course that the different server reside in different OUs, on a per department base.

    Here an example:

    Operations Manager Dynamic Group Examples

    If they are not in the same OU, then you can take IP range for a criteria or some other parameter, it doesn't matter, SCOM can cover pretty much everything.

    So to sum it up:

    - Read the blog post first. Think about how those recommendations apply in your case.

    - Think of what criteria you can use to build the SCOM groups with dynamic memberships.

    - Keep It Simple and don't over engineer, because otherwise you can get lost pretty quickly.

    Ask here and you will get help if you need more information or something is not clear.

    Best Regards


    Stoyan (Please take a moment to "Vote as Helpful" and/or "Mark as Answer" where applicable. This helps the community, keeps the forums tidy, and recognizes useful contributions. Thanks!)

    Tuesday, February 21, 2017 4:38 PM
  • Hi Birdal,

    To 1:

    After you install SCOM, there is a management pack there, called "Default Management Pack". There have been cases where users store all their configurations and/or overrides in this management pack. Not a good idea at all. You should store overrides on a per MP basis, separate the overrides somehow.

    To 2:

    You could go for storing overrides on a per version base, like you mentioned - one MP for SQL 2012 overrides, one for SQL 2014 overrides and so on, but this would be a bit of over engineering, especially in small and medium deployments. Instead, you can store all overrides for SQL in the same Unsealed MP. This would mean, that if you remove the Override MP, your config will default to the MP config. This is what is meant with unsealed MP per sealed MP. Example:

    - One Unsealed MP for the Active Directory MP
    - One unsealed MP for the Exchange MP
    - One unsealed MP for the Windows Server MP

    If you want to do it more granular, then you can go ahead and create:

    - One MP for overrides for Winows Server 2008 R (Windows Server MP)
    - One MP for override for Windows Server 2012 R (Windows Server MP)
    - etc.

    Like I said this could justified in some cases or could be over engineering in other. It would depend on yur requirements and the environment.

    To 3:

    Here you can decide or yourself how can you store configurations. This is just an example:

    - One MP for the Finance department where you store all the SCOM Groups with dynamic membership for example, bit NOT overrides. You have to be careful not to store override in a config MP, because then you will lose the overview of what is stored where.
    - One MP for the Accounting for exampple, containing the configuration like groups for example. Again no overrides, only config.

    This approach let's you separate MPs for overrides from MPs for configuration, giving you more options to manage them. This way, when you remove an old MP (for example SQL 2008 is not present any more, you remove the overrides MP), but your department configs are retained.

    Hope this makes it a bit clear.

    Regards,


    Stoyan (Please take a moment to "Vote as Helpful" and/or "Mark as Answer" where applicable. This helps the community, keeps the forums tidy, and recognizes useful contributions. Thanks!)



    • Edited by Stoyan ChalakovMVP Wednesday, February 22, 2017 10:29 AM
    • Proposed as answer by Yan Li_ Monday, March 6, 2017 3:54 AM
    • Marked as answer by _Birdal Monday, May 8, 2017 8:02 AM
    Wednesday, February 22, 2017 10:22 AM

All replies

  • Hi Birdal,

    To "We want to define our own sealed Management Packs for above listed monitorings."

    You can start with unsealed management packs and when you think the configurations there are complete, seal them so that they can be referenced.

    To "We want to create separate sealed Management Packs for each department/division."

    To be honest - I don't like that. It is best practice to store overrides of default management packs in unsealed MPs and have one Unsealed MP per Sealed MP (this is general approach and can vary a bit). If you want further separating this on department basis, this will lead to a handful of MPs, which is not a good approach. In my humble opinion you should reconsider this.

    I would go ahead and store override of sealed MPs in an unsealed MP (you can seal it later) and have one Unsealed MP per Sealed MP and then create MPs for the configurations (Groups, custom configs based on department, etc.) in separate, per department MPs...

    Let me suggest something. Start here:

    System Center Service Manager / Operations Manager Management Pack and Naming Convention Best Practices

    Read it carefully and then re-think your strategy. You will understand why I am asking you this after you finished reading the post. It has lots of real examples in it and they will answer some of your questions. Afterwards you can develop a strategy for the MPs.

    To "We want to make an automatically sorting of the server objects (Windows and Linux) into each group in relation to department/division."

    In SCOM you can create groups with dynamic memberships. This is the way to go in this case.

    You will have to define the criteria for the membership like for example OU in Active Directory. And then create groups with dynamic members. This will require of course that the different server reside in different OUs, on a per department base.

    Here an example:

    Operations Manager Dynamic Group Examples

    If they are not in the same OU, then you can take IP range for a criteria or some other parameter, it doesn't matter, SCOM can cover pretty much everything.

    So to sum it up:

    - Read the blog post first. Think about how those recommendations apply in your case.

    - Think of what criteria you can use to build the SCOM groups with dynamic memberships.

    - Keep It Simple and don't over engineer, because otherwise you can get lost pretty quickly.

    Ask here and you will get help if you need more information or something is not clear.

    Best Regards


    Stoyan (Please take a moment to "Vote as Helpful" and/or "Mark as Answer" where applicable. This helps the community, keeps the forums tidy, and recognizes useful contributions. Thanks!)

    Tuesday, February 21, 2017 4:38 PM
  • Hello,

    As we know, there are management packs that published by Microsoft and also some third parties, like Windows Server Operating System Management Pack, I would like to use those management pack, and then tune them according to business needs. 

    In SCOM, there are Windows group and Linux group defined for different Operating System. If you want to customize your own group, you can create your own one with Create Group Wizard.


    Please remember to mark the replies as answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, February 22, 2017 6:35 AM
  • Hi Stoyan,

    thank you for your quick feedback and information. I will read these articles and more then I will give you my feedback to discuss about it.

    Best Regards

    Birdal 

    Wednesday, February 22, 2017 8:01 AM
  • Hi Stoyan,

    I have just read Antoni's article. I think I must read it again. But I am not sure whether I understood it correctly in some points:

    1) What does Author mean with "Default Management Pack" in the sentence "Do not store anything in the Default Management Pack"? Does he mean all MPs from Microsoft which are imported into SCOM? 

    2) Create an override unsealed MP for each sealed Microsoft product MP?

    It means create override unsealed MPs, for example, "Override SQL 2016", "Override SQL 2012", "Override Windows 2016", "Override Windows 2012", and so on...

    3) Create another unsealed custom MP (customization MP) for each Microsoft product?

    It means create for the 1.Department "1.Department MP SQL 2016", "1.Department MP SQL 2012", "1.Department MP Windows 2016", "1.Department MP Windows 2012", and so on... Repeat all for each department, 2.Department, and so on?

    Have you other reference links for Authoring?

    Best Regards

    Birdal

    Wednesday, February 22, 2017 10:05 AM
  • Hi Birdal,

    To 1:

    After you install SCOM, there is a management pack there, called "Default Management Pack". There have been cases where users store all their configurations and/or overrides in this management pack. Not a good idea at all. You should store overrides on a per MP basis, separate the overrides somehow.

    To 2:

    You could go for storing overrides on a per version base, like you mentioned - one MP for SQL 2012 overrides, one for SQL 2014 overrides and so on, but this would be a bit of over engineering, especially in small and medium deployments. Instead, you can store all overrides for SQL in the same Unsealed MP. This would mean, that if you remove the Override MP, your config will default to the MP config. This is what is meant with unsealed MP per sealed MP. Example:

    - One Unsealed MP for the Active Directory MP
    - One unsealed MP for the Exchange MP
    - One unsealed MP for the Windows Server MP

    If you want to do it more granular, then you can go ahead and create:

    - One MP for overrides for Winows Server 2008 R (Windows Server MP)
    - One MP for override for Windows Server 2012 R (Windows Server MP)
    - etc.

    Like I said this could justified in some cases or could be over engineering in other. It would depend on yur requirements and the environment.

    To 3:

    Here you can decide or yourself how can you store configurations. This is just an example:

    - One MP for the Finance department where you store all the SCOM Groups with dynamic membership for example, bit NOT overrides. You have to be careful not to store override in a config MP, because then you will lose the overview of what is stored where.
    - One MP for the Accounting for exampple, containing the configuration like groups for example. Again no overrides, only config.

    This approach let's you separate MPs for overrides from MPs for configuration, giving you more options to manage them. This way, when you remove an old MP (for example SQL 2008 is not present any more, you remove the overrides MP), but your department configs are retained.

    Hope this makes it a bit clear.

    Regards,


    Stoyan (Please take a moment to "Vote as Helpful" and/or "Mark as Answer" where applicable. This helps the community, keeps the forums tidy, and recognizes useful contributions. Thanks!)



    • Edited by Stoyan ChalakovMVP Wednesday, February 22, 2017 10:29 AM
    • Proposed as answer by Yan Li_ Monday, March 6, 2017 3:54 AM
    • Marked as answer by _Birdal Monday, May 8, 2017 8:02 AM
    Wednesday, February 22, 2017 10:22 AM
  • Hi Stoyan,

    can you perhaps lookt at my new ticket related to MPs, Groups, etc., if you have time?

    https://social.technet.microsoft.com/Forums/en-US/0e543a30-4a2a-4759-aaa0-ae9be03bfbb7/scom-2016-authoring-management-packs-groups-targetings-related-to-file-servers?forum=operationsmanagerauthoring

    Thanks in advance.

    Best Regards

    Birdal

    Friday, June 23, 2017 10:41 AM