Setting up a new SCOM Enviroment best practice pointers RRS feed

  • Question

  • Hello

    I currently have SCOM 2007 R2 and am looking to implement SCOM 2012 R2. We have decided to start a fresh and start with a new Management Group (rather than upgrade the existing SCOM 2007 R2 environment, as there is a lot of bed practice, lessons learnt we do not want to bring over to the new environment).

    I am looking for some practical advise please on how to avoid pitfalls down the line.

    For example, in the past as was recommend when installing a new MP, I would create a new unsealed MP to store any overrides for the newly imported sealed MP. So lets say I imported a MP called "System XZY" I would then create an unsealed MP called "Override SYSTEM XYZ" now on the surface that looks fine, but when you sort in the Console they do not end up next to each other due to the console sorting alphabetically on the first letter.

    Therefore I should have called the MP "System XYZ Override" and the same for the others too, they way they would of all sorted next to one another sealed and its equivalent unsealed MP.

    The above is a very simply example of where doing some thing one way although looks OK at the start would have been much better to do another way.

    Also when it comes to Groups in used to create a group in an unsealed MP (e.g. the override MP) relevant to the rule/monitor application in question. The issue is as you know with unsealed MP you cannot reference the Group from another MP. Therefore if I needed to reference the same group of computers again for another reason MP I could not without creating another Group and thereby duplication and more work for the RMS to do populating/maintaining these groups.

    However I have also read that creating and MP for Groups then sealing and unsealing to add more groups etc. can be an issue on its own, not sure they this sealing/unsealing of a MP dedicated to Groups would be an issue, perhaps someone has experience of this and can explain?

    I would be very grateful for any advise (URL to document etc.) which best practice tips, to help avoid things such as the above down the line.

    Thanks all in advance



    Sunday, February 9, 2014 7:34 PM


All replies