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.
TIPS
- 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.
- It is also recommended to only install those management packs you need, as extra rules (and monitors in OpsMgr 2007) 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 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 rule generating an alert or threshold value that is inappropriate for your particular environment. You can tune this by changing the default settings.
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 your monitoring environment. 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. Start by looking at Alerts, then drill into other areas of the console as applicable.
Managing Alerts
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. You should document your actions by adding Company Knowledge.
Review the 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 the operational database.
Tuning Tips
- Review any new alerts reported for servers monitored with the new management pack. You can use reports provided by Microsoft 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 rule as applicable.
- Disable the 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 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.
- If a new management pack generates a ton of alerts, you may want to start by disabling rules within the that management pack. You can turn them on gradually, making the new management pack easier to tune and troubleshoot.
Finished?
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.
This is an abbreviated excerpt of tuning information included in Microsoft Operations Manager 2005 Unleashed and updated in the forthcoming book, Microsoft System Center Operations Manager 2007 Unleashed. You can also read about other tuning tips and techniques at the Windows Live OpsMgr blog, https://ops-mgr.spaces.live.com/.
