locked
Managment Pack Administration RRS feed

  • Question

  • We are using OpsMgr R2.  As our system matures, we will have the need to create various management packs for the different support areas.  Thinking through this, several questions come to mind.

    1)  Is there a limit to the number of management packs that can be imported into the system?  I'm thinking we could end up with hundreds.

    2)  Change Control.  We have a pre-prod environment.  What is the best way for managing our MPs?  Authoring, testing... all those items that encompass best practices.  We want a repeatable, low-risk process.

    3)  Once the MP is in Prod, when we create an override for a specific computer per a user's request, once we hit apply, is it correct that the new configuration goes out to all managed agents?  If so, and we have multiple overrides, are we continually sending out updated configurations and is there any concern there?

    4)  What is a worst-case scenario for MP creation/imports/updates?  In other words, are there some things we should be aware of NOT to do in our Prod environment as we could adversely affects all agent systems or bring down the RMS?

    Looking for direction on things to do and not to do to help us maintain an effective, available, system.

    Thank you,

    Kate

     

    Thursday, April 15, 2010 2:35 PM

Answers

  • There is a lot of best practice advice to be had on change control and managing management packs.  Mature solutions already are on the market to help companies get started quickly. 

    Things to NOT do

    1.  Do not put overrides in the default MP.  The default MP is ok for getting a demo to work or test how to create overrides - but over time if you put all overrides in default mp file, you will run into configuration churn, performance problems and limit your recoverery capabilities.

    2.  Overly complicate your MP design.  It isn't the number of MP's that causes problems (although thousands are beyond the design limit of the software) - but mainly overly complex file structures, unnessary inheritence graphs, and unexpected side effects from making a poor base class selection.

    3.  Do NOT use Windows.computer as a target for monitor - this will cause all kinds of chaos.

    4. Do NOT inherit from Windows.Computer for a class you discover.  If you need a CMDB, buy a CMDB (for SA customers, Service Manager is a sweet deal!).  Doing so will cause extra copies of workflows to run in unexpected places.

    Things to do

    1.  DO start learning more before you get started.  There are some excellent experts hanging out here and on SystemCenterCentral.

    2.  DO evaluate MP management solutions that are commerically available.  Thinking you can create it all in house cheaper is a noob mistake.

    3.  DO keep your pre-prod and prod environments.  overrides should NOT be created in production - they should be created in sidecar MP files (one per file set for a given MP you create) in your pre-prod or test environment, then migrated as an import step.  Making overrides in production can be horribly performance intensive because all updates are sent as soon as you save a single change.  By making them in your pre-prod environment and migrating the override file, you have control

    4.  DO lock down the number of people who have administrator permissions on your production console. Only the most process focused admins should be allowed the keys to production - change control works best when it also applies to monitoring.  If you have "wild and wooly" types who cannot respect a rigorous change control regimin, demote them to read-onlypermissions in production and let them design overrides in pre-prod and then submit requests to have their side-car files migrated to production

    5.  DO test and tune every MP in pre-prod so that when you take it to production, it arrives already tuned.  Most MP's you get are set to "maximum noise" mode so you need to turn off the rules and monitors you don't need.  Ideally, you have a pre-prod MP creating ZERO alerts that are not also one:one with actual problems that are operationally actionable.

     


    Microsoft Corporation
    Thursday, April 15, 2010 2:55 PM
  • Hi Cony

    Agree that you should not target windows computer - in general, as  Ake says, it is important to be as specific as possible. Ideally, create a class and target that. For a service you could do a registry based discovery using the authoring console for the existance of the registry key or include the value for startup type 2 (automatic).

    But as you are sure that every windows based agent has this service then my suggestion above was to do what the Windows MP does (and is also suggested by the poster called Rule and Monitor Targeting Best Practices) which is to target Window Server Operating System 200x
    http://go.microsoft.com/fwlink/?LinkId=125048

    Cheers

    Graham


    View OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/
    Tuesday, April 20, 2010 7:14 PM

All replies

  • There is a lot of best practice advice to be had on change control and managing management packs.  Mature solutions already are on the market to help companies get started quickly. 

    Things to NOT do

    1.  Do not put overrides in the default MP.  The default MP is ok for getting a demo to work or test how to create overrides - but over time if you put all overrides in default mp file, you will run into configuration churn, performance problems and limit your recoverery capabilities.

    2.  Overly complicate your MP design.  It isn't the number of MP's that causes problems (although thousands are beyond the design limit of the software) - but mainly overly complex file structures, unnessary inheritence graphs, and unexpected side effects from making a poor base class selection.

    3.  Do NOT use Windows.computer as a target for monitor - this will cause all kinds of chaos.

    4. Do NOT inherit from Windows.Computer for a class you discover.  If you need a CMDB, buy a CMDB (for SA customers, Service Manager is a sweet deal!).  Doing so will cause extra copies of workflows to run in unexpected places.

    Things to do

    1.  DO start learning more before you get started.  There are some excellent experts hanging out here and on SystemCenterCentral.

    2.  DO evaluate MP management solutions that are commerically available.  Thinking you can create it all in house cheaper is a noob mistake.

    3.  DO keep your pre-prod and prod environments.  overrides should NOT be created in production - they should be created in sidecar MP files (one per file set for a given MP you create) in your pre-prod or test environment, then migrated as an import step.  Making overrides in production can be horribly performance intensive because all updates are sent as soon as you save a single change.  By making them in your pre-prod environment and migrating the override file, you have control

    4.  DO lock down the number of people who have administrator permissions on your production console. Only the most process focused admins should be allowed the keys to production - change control works best when it also applies to monitoring.  If you have "wild and wooly" types who cannot respect a rigorous change control regimin, demote them to read-onlypermissions in production and let them design overrides in pre-prod and then submit requests to have their side-car files migrated to production

    5.  DO test and tune every MP in pre-prod so that when you take it to production, it arrives already tuned.  Most MP's you get are set to "maximum noise" mode so you need to turn off the rules and monitors you don't need.  Ideally, you have a pre-prod MP creating ZERO alerts that are not also one:one with actual problems that are operationally actionable.

     


    Microsoft Corporation
    Thursday, April 15, 2010 2:55 PM
  • Dan,

    In number three you mentioned to not use Windows.computer as a target.

    My question is - If I want to monitor a service on Windows 2008, Windows 2003, and a few business critical XP mahines what would I select as a target. Agent.managed would not work because of Linux servers.

    Cony

     

    Thursday, April 15, 2010 5:18 PM
  • I have the same question. What is the best way to target applications? Can you give some examples on how you would target a rule/monitor?

    Also If I disable the monitor by default and override it to a group. will that MP get distrbuted every where

    Thursday, April 15, 2010 6:46 PM
  • I think MS might recommend you target Windows Server Operating System, or something like that.  In our case that doesn't work due to the distributed way we route alerts to our ticket system.  If I target something at Windows OS, the alert might get sent to the wrong team.  Since we don't automatically forward anything from the Windows Server class, I have targeted that in the past.

    They might also recommend you create your own class to which you would target service monitors.  Lately I have taken this approach as I believe it to be "cleaner" and better in line with best practices which is to target as specifically as possible.  I feel your pain.


    Layne
    Thursday, April 15, 2010 9:00 PM
  • Here is some information on choosing a base class if you're authoring a Management Pack.

    http://technet.microsoft.com/en-us/library/ee957009.aspx

    Target more specifically is good, as is storing the monitoring in an MP that is specific to the application (if you're monitoring a specific app).

    Targeting very broad classes has a side effect in that very large numbers of agents have to run that monitoring, it also means that the MP where the monitoring is defined gets distributed to very large sets of agents, which puts more pressure on the infrastructure as well as agents.

    A possible way to create your own classes if you are using the OM console to author is to use attributes.

    The importance of following these practices grows with the number of custom rules and monitors you create.


    This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm
    Friday, April 16, 2010 2:06 AM
  • Ake,

    In our case this backup service is installed on every Windows 2003, Windows 2008, and Business Critical XP machines.

    We created a seperate MP for this service and created a new group that has dynamic membership of Windows 2003 computer group, Windows 2008 computer group, and Business Critical XP group (This limits to just those XP machines we put in Critical group).

    I don't see how creating an attribute that would be on each of the machines would be different.

    Cony

     

    Friday, April 16, 2010 12:40 PM
  • Hi Cony

    The out of the box core windows service monitoring is targeted at the Windows 200x operating system class so you may want to target this for consistency --> you can see them under Authoring > Management Pack Objects > Monitors > Windows 200x operating system > Entity Health > Availability 

    I'm not sure what you mean by "created a new group that has dynamic membership of Windows 2003 computer group, Windows 2008 computer group" but be careful as grouping for targetting doesn't always work the way you expect. You can target overrides at groups but not base monitoring.

    Cheers

    Graham


    View OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/
    Tuesday, April 20, 2010 8:53 AM
  • Graham,

    Dan mentioned that we should not target Windows.computer class.

    What we want to do is monitor a backup service on all of our Windows XP, Windows 2000, Windows 2003, and Windows 2008 machines.

    What would you suggest we use as a target to get this accomplished If we can only target one class?

    Or

    should we create 4 seperate basic service monitors and target each operating system seperately?

    thanks,

    Cony

     

    Tuesday, April 20, 2010 6:38 PM
  • Hi Cony

    Agree that you should not target windows computer - in general, as  Ake says, it is important to be as specific as possible. Ideally, create a class and target that. For a service you could do a registry based discovery using the authoring console for the existance of the registry key or include the value for startup type 2 (automatic).

    But as you are sure that every windows based agent has this service then my suggestion above was to do what the Windows MP does (and is also suggested by the poster called Rule and Monitor Targeting Best Practices) which is to target Window Server Operating System 200x
    http://go.microsoft.com/fwlink/?LinkId=125048

    Cheers

    Graham


    View OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/
    Tuesday, April 20, 2010 7:14 PM
  • Thanks Graham
    Wednesday, April 21, 2010 2:06 PM
  • Graham,

    I setup a dynamic group as the target and used Windows OS as the object for filling the group (Targeting and Monitoring Best Practices)

    When we deploy the MP no discovery takes place of the service.

    The group is being populated with windows os server names.

    It looks to me that discovery uses windows computer as the target (the group only contains Window OS objects)

    We are using the Windows Service Templated Supplied by OpsMgr

    I

    Bob

     

    Friday, April 23, 2010 4:51 PM
  • Hi

    If you are using the Authring Template then all the above is irrelevant becuase, as you say, you need to target what has already been chosen for you by the template. Outside of the template you should never target a group for a rule - you can target overrides at groups but not base rules \ monitors.

    For the authoring template see here for a full walkthrough:

    http://systemcentersolutions.files.wordpress.com/2009/11/servicemonitoring.pdf

    Cheers

    Graham


    View OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/
    Friday, April 23, 2010 8:14 PM