Management pack structure RRS feed

  • Question

  • I am working with a company to develop a new management pack. The developer that I am working with wants to break down the MP into several smaller MPs. I don't know of anything stating why or why not this should be done. I have looked at some of the management packs that MS has built and see several different files being used but I am unsure of the reason or the requirements, so I have several questions.

    1. Is there a maximum size that a management pack file should not exceed?
    2. Is there a recomended set of files that should be created? (Library, Discovery, Monitoring, Rules, ...)
    3. If I do break them down into a set of files, how do reference a class and properties from another file? Is it even posslible? I have tried this and am not having any luck so far.

    Any information you can point me to or fill in for me would be great.
    Monday, November 23, 2009 4:52 PM


  • Hi, I can try to answer by discussing an example, the Exchange 2007 MP. This is broken up into several files. From the MP Guide

    File name Description


    Contains discoveries and common monitoring that applies to all Exchange servers


    Contains class definitions


    Contains Client Access server (CAS) role monitoring


    Contains Edge server role monitoring and discoveries


    Contains Hub server role monitoring


    Contains Mailbox server role monitoring


    Contains Unified Messaging server role monitoring and discoveries


    Contains Reports for the Mailbox, Hub, and Client Access server roles.


    Contains Exchange 2007 reports using the Operations Manager R2 Service Level Management Reporting feature. Note that this is an unsealed management pack.


    Contains the Mail Flow and Client Access server synthetic transaction templates.

    There are several reasons for using this structure
    1. The MP is a relatively good citizen in the Management Group - the relevant MPs are only downloaded where they actually apply. This reduces impact (network traffic, OM server load, agent load etc). If you use a single MP, this will go everywhere. Don't forget the impact of overrides as well, this will also go everywhere when you create an override for your MP.
    2. The user can choose not to import optional MPs (For example the Edge and UM server roles are optional in an Exchange 2007 installation, reporting is optional in an OM installation). This reduces clutter for the user in places like views and the "Management Packs" list in the Console.
    3. Easier authoring (easier to find stuff, particularly in a very large MP like the EXchange 2007 one)
    4. Some MPs choose to bring forward the library across MP versions and create subclasses for version-specific classes. An advantage here is that things like views can be targeted to the base class (like SQL Server), it's then very easy for the user to see all SQL servers (2000, 2005, 2008) in a single view, irrespective of version.

    Cons with this approach is adding some complexity for the user to figure out what the MP actually does and what needs to be imported. I'm personally not a fan of the "import the MP and let's see what happens" approach.

    There are other related things to think about like scoping your discoveries to the relevant base class (if your app only runs on servers, scope your initial discovery to servers, not computers).

    The Exchange 2007 MP actually goes a step further by turning discovery off by default, it finds the agent-managed Exchange servers but does not apply any monitoring until the user overrides a set of role-based discoveries. This allows the user to deploy and tune the MP at a pace he's comfortable with. Again, this will cause some overhead/confusion on the users side and force them to read the MP documentation. The main benefit is user control - the informed user can decide what's appropriate for his/her environment.

    Look at the authoring resource kit for some useful tools like the MP Best Practice Analyzer.

    I am not aware of a max size for an MP. You can addres MP elements in other MPs by declaring them in the References section of the MP.
    <Reference Alias="ExLibrary">

    and reference it like this (in this case a RunAs reference)
    <DataSourceModuleType ID="Microsoft.Exchange2007.TestImapConnectivity.DS" Accessibility="Internal" RunAs="ExLibrary!Microsoft.Exchange2007.Account.LocalSystem" Batching="false">

    Some of this may not be relevant for your MP, but I think it comes down to
    * being a good MP citizen by reducing impact on the environment (remember the user may have hundreds of MPs imported)
    * optionally deciding whether you want the user to control MP deployment by disabling discovery or using a "seed" discovery that does not apply monitoring by default.

    I hope this makes some sense.

    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
    Monday, November 23, 2009 7:00 PM