locked
Force SCOM agent to exclude specific Managament Packs RRS feed

  • Question

  • The default behavior of the SCOM agent (Microsoft Monitoring Agent) is to download all Management Packs and stores them in "C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State\Cabinets". Is there any way to force the SCOM agent to exclude specific Management Packs?
    Thursday, October 1, 2015 7:15 AM

Answers

  • Hi

    No - there is no straight forward way to achieve this. Using connected management groups is certainly not a solution.

    Most Management Packs these days have a Discovery MP and a Monitoring MP. If you do not want the Monitoring MPs to go to an agent then you need to disable the discovery that underlies the monitoring.

    Regards

    Graham


    http://blogs.technet.com/b/manageabilityguys/

    • Proposed as answer by Stoyan ChalakovMVP Friday, October 2, 2015 9:26 AM
    • Marked as answer by Elton_Ji Tuesday, October 20, 2015 2:17 AM
    Friday, October 2, 2015 8:34 AM

All replies

  • I guess you can override>disable the "root" discovery (the one usually targeted at Windows Server) of the MPs you don't want to be downloaded
    Thursday, October 1, 2015 8:24 AM
  • I must admit that I don't really follow what you are saying... Exactly where do I "disable the root discovery"? Do you mean in the Authoring view?

    I'll clarify exactly why I would like the SCOM agent to exclude specific MPs.

    We use SCOM to monitor the majority of our customer's Windows servers. For some customers we have created specific Management Packs. For example "Customer A Inc. MP" and "Customer B Ltd. MP". What we've discovered is that the SCOM agent on ServerX that belongs to Customer A, also downloads the MPs for Customer B (Customer B Ltd. MP). Is there anyway to force the SCOM agent on ServerX not to download the MP for Customer B?

    Thursday, October 1, 2015 10:59 AM
  • Using "Connected Management Groups" might have been cleaner in the first place ( https://technet.microsoft.com/en-us/library/hh230698.aspx ), but I understand it can't always be realistic depending on many things.

    So, back to your issue : 

    What happens is that your "Customer A MP" and "Customer B MP" most likely have rules targeted to the same classes (let's say Windows Computer), so they are obviously sent to any instance of that class  (= any agent running on a Windows Computer), regardless of what customer that instance belongs.

    What you could do about this is disable every rule targeted to that kind of generic class and then override>enable it for a given group containing the computers of Client A or Client B. 

    And yes, you do this in Authoring view :)

    • Proposed as answer by CyrAz Friday, October 2, 2015 12:03 PM
    Thursday, October 1, 2015 12:04 PM
  • Much appreciated and a good suggestion. Thank you!

    I will investigate and test this.  I will reply if successful or not.

    Friday, October 2, 2015 7:59 AM
  • Hi

    No - there is no straight forward way to achieve this. Using connected management groups is certainly not a solution.

    Most Management Packs these days have a Discovery MP and a Monitoring MP. If you do not want the Monitoring MPs to go to an agent then you need to disable the discovery that underlies the monitoring.

    Regards

    Graham


    http://blogs.technet.com/b/manageabilityguys/

    • Proposed as answer by Stoyan ChalakovMVP Friday, October 2, 2015 9:26 AM
    • Marked as answer by Elton_Ji Tuesday, October 20, 2015 2:17 AM
    Friday, October 2, 2015 8:34 AM
  • My understanding of this issue is that un monitors different infrastructures from different customers. Deploying a management group for each of these customers and then consolidating them with connected management groups sounds to me like a possible option, if it had been done at the begining. Of course it's not a solution anymore.

    For the rest, I wasn't too sure whether their "Customer MP" were real proper MPs or just a bunch of rules and winzard-generated monitors, hence my two different replies about "disabling root discoveries" and "disable every rule and monitor targeted at windows computers"


    • Edited by CyrAz Friday, October 2, 2015 9:10 AM
    Friday, October 2, 2015 9:10 AM
  • Sorry - should have been more specific. I meant - given that they are all in one management group, there is no way to get to a multiple MG scenario without starting again. Connected Management Groups might have been an option from a "fresh start" albeit there would be added cost of infrastructure \ administration from multiple management groups. All they can really do now is disable discoveries or monitors.

    It appears that the solution hasn't really been thought through when it was initially designed.

    Regards

    Graham


    http://blogs.technet.com/b/manageabilityguys/

    Friday, October 2, 2015 9:18 AM