I’d like to point you over to this thread on the TechNet forums. It’s a list of dos and don’ts regarding MP administration and lifecycle, there is some great stuff in there.
Credit for this goes to Dan Rogers of Microsoft.
Here’s the good part (links added by me for clarity):
Things to NOT do
1. Do not put overrides in the default MP. The default MP is ok for getting a demo to work or test how to create overrides - but over time if you put all overrides in default mp file, you will run into configuration churn, performance problems and limit your recovery capabilities.
2. Overly complicate your MP design. It isn't the number of MP's that causes problems (although thousands are beyond the design limit of the software) - but mainly overly complex file structures, unnecessary inheritance graphs, and unexpected side effects from making a poor base class selection.
3. Do NOT use Windows.computer as a target for monitor - this will cause all kinds of chaos.
4. Do NOT inherit from Windows.Computer for a class you discover. If you need a CMDB, buy a CMDB (for SA customers, Service Manager is a sweet deal!). Doing so will cause extra copies of workflows to run in unexpected places.
Things to do
1. DO start learning more before you get started. There are some excellent experts hanging out here [TechNet Forum] and on SystemCenterCentral.
2. DO evaluate MP management solutions that are commercially available. Thinking you can create it all in house cheaper is a noob mistake.
3. DO keep your pre-prod and prod environments. overrides should NOT be created in production - they should be created in sidecar MP files (one per file set for a given MP you create) in your pre-prod or test environment, then migrated as an import step. Making overrides in production can be horribly performance intensive because all updates are sent as soon as you save a single change. By making them in your pre-prod environment and migrating the override file, you have control
4. DO lock down the number of people who have administrator permissions on your production console. Only the most process focused admins should be allowed the keys to production - change control works best when it also applies to monitoring. If you have "wild and woolly" types who cannot respect a rigorous change control regime, demote them to read-only permissions in production and let them design overrides in pre-prod and then submit requests to have their side-car files migrated to production
5. DO test and tune every MP in pre-prod so that when you take it to production, it arrives already tuned. Most MP's you get are set to "maximum noise" mode so you need to turn off the rules and monitors you don't need. Ideally, you have a pre-prod MP creating ZERO alerts that are not also one:one with actual problems that are operationally actionable.
Matt.
