locked
Newbie question - Overrides and best practice - can't locate originated management pack RRS feed

  • Question

  • Hi,

    Completely new to SCOM, been working with HP monitoring products for years, and it is safe to say that they are very different.

    Best practice concerning overrides in the help-section states the following:

    "As a best practice, when you set overrides for a management pack, save them to a management pack that is named ManagementPack_Overrides, where ManagementPack is the name of the sealed management pack to which the overrides apply. For example, overrides to the management pack Microsoft.InformationWorker.Office.XP.mp would be saved to Microsoft.InformationWorker.Office.XP_Overrides.xml."

    I am trying to do some overrides of the Active Directory-packs, currently 5 packs are installed and I have made  override-packages to all of them according to the instruction above. Problem is that when I go into an alert to override it(right-clicking the alert etc) I don't know which *_overrides.xml to save to because I can't find out which original MP pack the rule\alert come from. How am I able to follow up on best practice?

    Thanks in advance,

    Best Regards

    Thursday, May 10, 2012 1:35 PM

Answers

  • The best practice I always impart on my customers is the following:

    1. Create a new override MP that has a direct relationship to the management pack you are overriding that will apply to all agents algined with that IT or Business service and use the name of the vendor MP in the name of your override MP to make it easy/understandable with what those overrides align to.  Example - Making overrides to the Active Directory 2008 MP, create a MP called:  OR - Microsoft Windows Server Active Directory 2008.  Now you can make it even more generic so that if you have AD 2003 and AD 2008 in your environment and are monitoring both, you create an override MP for each and in doing so, when you decommission AD 2003 in your environment and no longer need to monitor it, you can remove that MP and the MP hosting the overrides. 

    2. Another approach is to group overrides according to the IT support group or Business Service (i.e. Line of Business application being monitored).  This way you are managing based on the monitoring requirements of that group as it relates to the IT or Business Service they are responsible for since they may have monitoring requirements that are not in alignment with the global standards.  Example - they may have specific thresholds for Available Disk Space versus the other IT groups. 

    Also to help you track your changes, I strongly encourage using a spreadsheet to document the overrides implemented (What - target, rule/monitor, parameter modified, Who made the change, Why the change was made, When it was made).  In addition, leverage your existing Change Management process (if exists in your IT organization) will help bring efficiency, structure, consistency and oversight. 

    Hope that helps.


    • Edited by Matt Goedtel (MSFT) Thursday, May 10, 2012 1:57 PM Mispelled word in my response.
    • Marked as answer by Nicholas Li Wednesday, May 23, 2012 3:36 AM
    Thursday, May 10, 2012 1:56 PM
  • If you find that same monitor/rule in the AUTHORING tab of the SCOM console you can see which management pack it resides in.  So, instead of overriding from the monitoring space in the SCOM console, use the authoring tab.

    So alert comes in you want to modify.  Click on the rule/alert to see what it is.  That will show you what it is targeting and what management pack it is in.  Also make sure that this is not a script generated alert from a monitor.  To figure that out right click on the alert and select open health explorer.  You might need to make a change to a monitor as well.

    This should solve all your problems, as all the data you need is presented in both monitoring and authoring space.


    Regards, Blake Email: mengotto<at>hotmail.com Blog: http://discussitnow.wordpress.com/

    • Marked as answer by Nicholas Li Wednesday, May 23, 2012 3:36 AM
    Thursday, May 10, 2012 3:53 PM
  • The best practice says Import the MP one by one, do not import all MP's just for the sake of having them. Test it out in staging environment first (if you have that flexibility) tune the MP, override monitors/rules accordingly and then same can be imported back to production environment.

    If you disable everything in the MP and enable one by one then possibility is that you might not know which rule/monitor has dependency on other.

    You may want to look at the below blog for AD MP checklist:

    http://blogs.technet.com/b/momteam/archive/2007/07/19/active-directory-management-pack-checklist.aspx 

    Thanks,

    Varun

    • Marked as answer by Nicholas Li Wednesday, May 23, 2012 3:36 AM
    Friday, May 11, 2012 9:31 AM
  • I wouldn't create overrides one at a time, but that is one way you can tackle this.  Most of my override MP's are created / tested in a lab, sealed and then imported into production.  This allows for one change update to agents, as compared to several when you are doing one off overrides in the console.

    You can also delete the mp if you are not benefiting from it.


    Regards, Blake Email: mengotto<at>hotmail.com Blog: http://discussitnow.wordpress.com/

    • Marked as answer by Nicholas Li Wednesday, May 23, 2012 3:36 AM
    Friday, May 11, 2012 2:43 PM
  • I think it is best to tackle the noise in the MP. generally the noise comes from not having added a runas account to the profile, having issues with trusts and contacting ops master roles and such. Also the DNS mp gives some noise like that. Generally some need to be fixed on the DC side and some need to be tuned in SCOM. Make sure you have the latest version of the management pack, that also helps. Overriding every single thing (disabling it) is probably not the greatest solution.

    Bob Cornelissen - BICTT (My Blog about SCOM) - MVP 2012 and Microsoft Community Contributor 2011 Recipient

    • Marked as answer by Nicholas Li Wednesday, May 23, 2012 3:37 AM
    Friday, May 18, 2012 3:14 PM

All replies

  • The best practice I always impart on my customers is the following:

    1. Create a new override MP that has a direct relationship to the management pack you are overriding that will apply to all agents algined with that IT or Business service and use the name of the vendor MP in the name of your override MP to make it easy/understandable with what those overrides align to.  Example - Making overrides to the Active Directory 2008 MP, create a MP called:  OR - Microsoft Windows Server Active Directory 2008.  Now you can make it even more generic so that if you have AD 2003 and AD 2008 in your environment and are monitoring both, you create an override MP for each and in doing so, when you decommission AD 2003 in your environment and no longer need to monitor it, you can remove that MP and the MP hosting the overrides. 

    2. Another approach is to group overrides according to the IT support group or Business Service (i.e. Line of Business application being monitored).  This way you are managing based on the monitoring requirements of that group as it relates to the IT or Business Service they are responsible for since they may have monitoring requirements that are not in alignment with the global standards.  Example - they may have specific thresholds for Available Disk Space versus the other IT groups. 

    Also to help you track your changes, I strongly encourage using a spreadsheet to document the overrides implemented (What - target, rule/monitor, parameter modified, Who made the change, Why the change was made, When it was made).  In addition, leverage your existing Change Management process (if exists in your IT organization) will help bring efficiency, structure, consistency and oversight. 

    Hope that helps.


    • Edited by Matt Goedtel (MSFT) Thursday, May 10, 2012 1:57 PM Mispelled word in my response.
    • Marked as answer by Nicholas Li Wednesday, May 23, 2012 3:36 AM
    Thursday, May 10, 2012 1:56 PM
  • If you find that same monitor/rule in the AUTHORING tab of the SCOM console you can see which management pack it resides in.  So, instead of overriding from the monitoring space in the SCOM console, use the authoring tab.

    So alert comes in you want to modify.  Click on the rule/alert to see what it is.  That will show you what it is targeting and what management pack it is in.  Also make sure that this is not a script generated alert from a monitor.  To figure that out right click on the alert and select open health explorer.  You might need to make a change to a monitor as well.

    This should solve all your problems, as all the data you need is presented in both monitoring and authoring space.


    Regards, Blake Email: mengotto<at>hotmail.com Blog: http://discussitnow.wordpress.com/

    • Marked as answer by Nicholas Li Wednesday, May 23, 2012 3:36 AM
    Thursday, May 10, 2012 3:53 PM
  • Thanks a lot!

    I also have one more question, we have the Active Directory MP installed because we're trying to monitor the whole server park. The AD MP is not an a high priority at the moment, but we heard that this should be installed if one adds domain controllers. Now I want to disable the whole MP because of the noise; is the best way to do this to create overrides for each alert\monitor that comes in, or is there some more efficient way?

    Thanx


    Thanks in advance, Best Regards

    Friday, May 11, 2012 8:53 AM
  • The best practice says Import the MP one by one, do not import all MP's just for the sake of having them. Test it out in staging environment first (if you have that flexibility) tune the MP, override monitors/rules accordingly and then same can be imported back to production environment.

    If you disable everything in the MP and enable one by one then possibility is that you might not know which rule/monitor has dependency on other.

    You may want to look at the below blog for AD MP checklist:

    http://blogs.technet.com/b/momteam/archive/2007/07/19/active-directory-management-pack-checklist.aspx 

    Thanks,

    Varun

    • Marked as answer by Nicholas Li Wednesday, May 23, 2012 3:36 AM
    Friday, May 11, 2012 9:31 AM
  • I wouldn't create overrides one at a time, but that is one way you can tackle this.  Most of my override MP's are created / tested in a lab, sealed and then imported into production.  This allows for one change update to agents, as compared to several when you are doing one off overrides in the console.

    You can also delete the mp if you are not benefiting from it.


    Regards, Blake Email: mengotto<at>hotmail.com Blog: http://discussitnow.wordpress.com/

    • Marked as answer by Nicholas Li Wednesday, May 23, 2012 3:36 AM
    Friday, May 11, 2012 2:43 PM
  • I think it is best to tackle the noise in the MP. generally the noise comes from not having added a runas account to the profile, having issues with trusts and contacting ops master roles and such. Also the DNS mp gives some noise like that. Generally some need to be fixed on the DC side and some need to be tuned in SCOM. Make sure you have the latest version of the management pack, that also helps. Overriding every single thing (disabling it) is probably not the greatest solution.

    Bob Cornelissen - BICTT (My Blog about SCOM) - MVP 2012 and Microsoft Community Contributor 2011 Recipient

    • Marked as answer by Nicholas Li Wednesday, May 23, 2012 3:37 AM
    Friday, May 18, 2012 3:14 PM