Deploying management packs involves planning, evaluating in a test environment, and finally importing the management pack along with any changes from test to your production environment. You also will want to decide which management packs you want to deploy, and in what order. Some applications have dependencies on others, so you may want to implement the related management packs as you deploy those products.
For example, say you use Exchange Server. Exchange requires Active Directory, which in turn utilizes DNS. You would want to first test and implement in order the dependencies, e.g. the DNS MP, then AD, and finally Exchange. Another consideration is where you might get the most "bang for the buck" – which management packs give you the most benefit for the least amount of cost (tuning, resources, or effort). The order in which you implement management packs will depend on the priorities of your organization and your goals for monitoring.
- It is best to introduce a single management pack at a time, as this practice makes it easier to deal with management pack issues as they occur. When there is more than one management pack involved it may be difficult to determine what initially caused a problem.
- We also suggest you only install those management packs you need, as extra rules and monitors impose a cost on your system resources; increased memory utilizations of the agents targeted by the management pack, and increased traffic between the managed computers and the management server.
Initial Tuning – By Function
Once you have determined your strategy and order for deploying management packs, it is time to import selected management packs one at a time into your test environment. As part of your approach, be sure to refer to that MP’s management pack guide. The MP guides discuss particulars for installing, configuring, and tuning that particular management pack. The management pack guides are typically included in the download package with the management pack.
It is of course, best to tune in a test environment as the impact of a badly-performing rule or monitor is less than in production. Testing pre-production also helps minimize the information load and unnecessary work for your production computer operators.
As you evaluate a management pack’s behavior you may decide to tune one or more parameters to meet your organization’s needs. For example, you may have a performance monitor generating an alert or threshold value that is inappropriate for your particular environment. You can tune that setting by overriding the default settings for that monitor.
You will either work on a server-by-server or application-by-application basis, tuning from the highest severity alerts and dependencies to the lowest.
A server-by-server approach addresses issues identified while deploying servers into OpsMgr. Once that is complete, your process should be an application-by-application / service-by-service basis, focusing on the overall health of the application or service. Look at alerts first, then open he Health Explorer to drill down specifically into the problem.
When you implement a management pack, it will generate alerts that you will want to review and evaluate for tuning. Some rules and monitors may generate low severity alerts, depending on your specific environment these may not be worth investigating or resolving, and you may consider disabling that rule or monitor. Any changes made are saved to an unsealed management pack. You can document your actions using the Company Knowledge section of the object.
Review the Operations console regularly to see whether information is captured that is unnecessary for your environment, as this could take up an excessive amount of storage within Operations Manager.
- Review any new alerts reported for servers monitored with the new management pack. You can use the Alerts and Most Common Alerts reports to help you discover your most common alerts.
- Resolve the issue generating the alert. Use the product knowledge base information regarding the specific error. When you first install a management pack, it tends to discover a multitude of previously unknown issues. Monitor the alerts to determine potential areas of concern
- Override the monitor or rule as applicable for a particular object type, a group, or a specific object.
- Disable the monitor or rule if the issue is not severe enough to warrant an alert and you do not need to be made aware of the specific situation being monitored.
- Change the threshold of the monitor that is generating the alert if you want the underlying condition to be monitored, but the alert is being generated before the condition is actually a problem for your particular environment. Remember OpsMgr incorporates self-tuning thresholds, so in many instances the system will do this for you.
- If a new management pack generates a ton of alerts, you may want to start by disabling monitors or rules within the that management pack. You can turn them on gradually, making the new management pack easier to tune and troubleshoot.
After you reach a comfort level with each management pack, it is time to put it into production. Because you’ve already "tuned" the MP and want to keep your changes, export your customizations from the test environment and then import that into production along with the vendor-provided management pack.
This is an abbreviated excerpt of tuning information from our forthcoming book, System Center Operations Manager 2007 Unleashed.