locked
Error when reimporting custom Management Pack RRS feed

  • Question

  • Hi Forums:

    I have a custom management pack of thousands of custom rules that we built during a MOM to OpsMgr rule migration.  We built the MP in a Sandbox OpsMgr environment with the intent of importing the MP into a production system at a later date.

    We exported the MP to an xml file, then deleted the MP from within the console.  Now, when we try to import the MP back into OpsMgr, it hangs for 15-20 minutes on "importing MP..."  then we get an error message:

    "CustomMPname" could not be imported.  If any managements packs in the Import list are dependent on this MP, the installation of the dependent managment packs will fail.

    The client has been disconnected from the server. Please call ManagementGroup.Reconnect() to reestablish the connection.

    We do not get any events in the Application, System, or Operations Manager logs..

    Any ideas?


    -- Ron Williams http://www.r0nwilliams.com
    Monday, July 12, 2010 6:16 PM

Answers

  • Couple of thoughts.  You could be hitting database transaction timeout - the MP is way too big.  Consider breaking it up into MP's that are 100K or less in size. 
    Microsoft Corporation
    Tuesday, July 13, 2010 3:47 AM
  • This management pack has thousands of nested group, and then rules targeted to the groups.


    This doesn't sound good for a few reasons.

    1. Our internal performance test team has tested with up to 1000 groups in a MG, and recommend not exceeding 1000 groups in a single MG or performance issues will bubble up...especially if these groups have expensive calculations and go beyond a couple levels.

    2. I've never understood the purpose of nested groups.  I think it was a concept that looked good on a drawing board in the initial design stages, but I have no good argument to use nested groups...ever.  It only serves as an organizational method, but really just hides things...which actually causes less organization and more confusion than what was intended.

    3. One of the first things we learn when creating monitors and rules is that we should not target a group.  Groups are owned and managed by the RMS, and will not work as you think they will in monitoring workflows.  Rather, target classes and types.  If the classes and type do not exist, author new classes and types that make sense for your monitoring scenario.  This is usually done on a management pack basis, which each MP discovering certain types of computers relavant to the monitoring scenario (usually application X or service X is installed or hosted on that computer).


    HTH, Jonathan Almquist - MSFT
    • Proposed as answer by Jonathan Almquist Wednesday, July 14, 2010 7:21 PM
    • Marked as answer by Yog Li Tuesday, July 20, 2010 11:43 AM
    Wednesday, July 14, 2010 7:18 PM

All replies

  • Couple of thoughts.  You could be hitting database transaction timeout - the MP is way too big.  Consider breaking it up into MP's that are 100K or less in size. 
    Microsoft Corporation
    Tuesday, July 13, 2010 3:47 AM
  • Hey Dan:

    We allowed the database to grow, and the import worked.

     

    This management pack has thousands of nested group, and then rules targeted to the groups.

    How woudl we go about splitting the MP.  woudl it involve hacking the XML into multiple files?

    The client spent about 240 man hours building the rules and groups in this managemnt pack, so completely recreating it woudl be very difficult.

    Is there a way to export all the rules into their own MP, then export all the groups into another?  We already have the rules targeted to groups within the MP, woudl we lose those links?


    -- Ron Williams http://www.r0nwilliams.com
    Tuesday, July 13, 2010 9:35 PM
  • Well, if growing the DB worked, you are out of the woods.  Realize that any change to that MP will cause the entire file to be re-sent to all angents involved - and this could cause considerable network, IO and configuraiton churn.  Does making a change and saving it in the console take a long time to complete?  If so, this is the symptom of system wide impact.

    Since you are out of the woods, and so much labor has been put into it, it is probably a no starter to split it up.  getting a federated set of groups that then are used to scope overrides is a big deal to get in place - and once an MP has been written, it is hard to split up due to the structure of the XML. 

    I'd say see how it goes.  If you can manage a large environment this way and the churn side effects are small, you probably have a win.


    Microsoft Corporation
    Wednesday, July 14, 2010 1:06 AM
  • Does the group nesting still work? in my experience group nesting fails when you delete a group and later reimport it, as the "UID" it gets changes.


    Rob Korving
    http://jama00.wordpress.com/
    Wednesday, July 14, 2010 7:36 AM
  • This management pack has thousands of nested group, and then rules targeted to the groups.


    This doesn't sound good for a few reasons.

    1. Our internal performance test team has tested with up to 1000 groups in a MG, and recommend not exceeding 1000 groups in a single MG or performance issues will bubble up...especially if these groups have expensive calculations and go beyond a couple levels.

    2. I've never understood the purpose of nested groups.  I think it was a concept that looked good on a drawing board in the initial design stages, but I have no good argument to use nested groups...ever.  It only serves as an organizational method, but really just hides things...which actually causes less organization and more confusion than what was intended.

    3. One of the first things we learn when creating monitors and rules is that we should not target a group.  Groups are owned and managed by the RMS, and will not work as you think they will in monitoring workflows.  Rather, target classes and types.  If the classes and type do not exist, author new classes and types that make sense for your monitoring scenario.  This is usually done on a management pack basis, which each MP discovering certain types of computers relavant to the monitoring scenario (usually application X or service X is installed or hosted on that computer).


    HTH, Jonathan Almquist - MSFT
    • Proposed as answer by Jonathan Almquist Wednesday, July 14, 2010 7:21 PM
    • Marked as answer by Yog Li Tuesday, July 20, 2010 11:43 AM
    Wednesday, July 14, 2010 7:18 PM