From experience I can tell you putting everything in one MP is a long term pain. A co-worker did this for two years resulting in a lot of work for this swing migration to the new environment. We will essentially have to redo all our monitors. On the plus side, we’ve learned a lot so should be able to take those lessons and apply them better now.
Use this time to update any practices and develop good internal documentation on this going forward. From: Henrik Andersen Sent: Friday, January 30, 2015 12:31 AM To: [email protected] One thing to observe, is that if you plan to use groups for overrides and the groups are placed in unsealed management packs, the override has to be placed within the same management packs. This applys to for custom monitors/rules too. /Henrik Fra: [email protected] [mailto:[email protected]] På vegne af Kevin Holman Sendt: 30. januar 2015 00:32 Til: [email protected] Emne: [msmom] RE: Custom Management Packs Best practice is NOT to place all customizations (overrides) in a single MP. This causes MP bloat in size and each time any change is made all agents must re-download this MP. Best practice is to create an override MP per technology, according to a documented naming standard. Such as: CompanyName - Overrides – Windows Server OS CompanyName - Overrides – SQL CompanyName - Overrides – IIS CompanyName - Overrides – Exchange CompanyName – Overrides – Citrix Then – also have different management packs for custom workflows: CompanyName – MyCorporateAntivirus MP CompanyName – MyCustomDevelopedApplication MP Companyname – Citrix MP Etc, etc. The reasons for this are: 1. Less impact on the network and all agents when a change is made. 2. MUCH less work when deleting management packs that no longer apply (such as deleting the SharePoint 2007 MP or the SCCM 2007 MP once those technologies are no longer used) If you create too many override MP’s, people tend to get lost and stick things in the wrong places…. so it is a balancing act depending on how many cooks are in the kitchen, and how mature standards are followed in the company. For very small environments, customers find it easier to just dump stuff in a single MP, because they never get into the “one unsealed MP cannot reference another unsealed MP” issue. However, that doesn’t change recommended practice. From: [email protected] [mailto:[email protected]] On Behalf Of Orlebeck, Geoffrey Sent: Thursday, January 29, 2015 3:01 PM To: '[email protected]' Subject: [msmom] Custom Management Packs Upgrading from SCOM 2007 to 2012 R2 and I noticed in our 2007 environment, all customizations reside in a single custom management pack. I am wondering if there is a best practice or if SCOM users with real world experience could chime in on which scenario is better: 1) A single management pack containing all customizations and overrides or 2) Breaking out management packs based on some convention: the rule/monitor, or the technology (application, etc.). I don’t really have any horses in this race, and maybe ‘better’ is a relative term in this instance. I am curious the pros/cons of each approach, or if with SCOM 2012 R2 there is a reason to choose one over the other. Thank you. Confidentiality Notice: This is a transmission from Community Hospital of the Monterey Peninsula. This message and any attached documents may be confidential and contain information protected by state and federal medical privacy statutes. They are intended only for the use of the addressee. If you are not the intended recipient, any disclosure, copying, or distribution of this information is strictly prohibited. If you received this transmission in error, please accept our apologies and notify the sender. Thank you.
