Follow-up from my MP Lifecycle Management TechNet Webcast

  • Article

Today I had the pleasure of presenting about System Center Operations Manager 2007 MP Lifecycle Management via TechNet Webcast.  After I completed the presentation I shortly realized I failed to mention some important facts/recommendations that I had notated yet overlooked due to time and a bit of nervousness.  I digress.  Anyway, here are a few things I would like to elaborate on or just highlight.

  1. The tools to augment your "toolkit" with respect to managing overrides, reviewing overrides in your management group, etc. can be downloaded off of Boris Yanushpolsky's Blog - https://blogs.msdn.com/boris_yanushpolsky/default.aspx.  Those tools I mentioned were Override Explorer and Override Creator.
  2. Another tool to augment your "toolkit" with respect to viewing the configuration of a management pack can be downloaded off of Boris Yanushpolsky's Blog - https://blogs.msdn.com/boris_yanushpolsky/default.aspx.  This tool is called MP Viewer.
  3. Silect MP Studio provides many features with respect to viewing the configuration of a management pack, performing overrides, test and tune the MP by running the feature "Resultant Set of Alerts", opening a management pack and printing out the default rules and monitors that are enabled so the SME/SO (Subject Matter Expert/Service Owner) can understand the scope of what is monitored and what default thresholds may be defined.  The Resultant Set of Alerts feature is valuable when verifying the management pack as part of your test phase.  Also their MPStuidoLite tool should be considered if you don't decide to purchase the MPStuido product.  I should also note that the folks at Silect are also working towards ensuring that the tool compliments the ITIL processes with respect to Change, Release, and Config.  You can find out more about it here - https://www.silect.com/solutions/opsmgr_Sol/opsmgr_Sol_studio.html.
  4. When conducting the pilot of your management pack, leverage the built-in reports Operations Manager - Microsoft Generic Report Library\Most Common Alerts and Microsoft ODR Report Library\Most Common Alerts.  These reports will help you in identifying the top offenders that may require additional tuning, adjusting the configuration of rule/monitor. or a logic error in a rule script.
  5. For the pilot phase I recommended multi-homing the agent managed system in production against the QA management group.  This allows you to narrow the scope of your pilot without having to deal with overrides for controlling the discovery rules that would identify systems that match the criteria required for the MP to begin monitoring the application or service.  Multi-homing allows you to distribute the monitoring between one or more management groups and the processing of rules is managed independently.  Meaning if I have my production management group monitoring the server/service/application using x version of a management pack and in the QA management group I have version y of the same management pack, the processing is independent.  It is like having two agents running on the same system (even though with MOM/OpsMgr 2007, it is one agent and the configuration information in the Registry dictates it reports to two separate management groups).  The multi-homed agent processes the workflows from the different configuration groups independently and there is no conflict of rules.
  6. The goal of the alert tuning process is to minimize the alert "noise" or the barrage of false alerts that have been generated and overshadow the relevant alerts that are actionable.  Sometimes the source of alert noise can be attributed to false positives, false negatives, and multiple alerts with the same root cause.  This is an on-going process and may not be resolved in a short period of time.  For further guidance, please review the MOM 2005 Alert Tuning Solution Accelerator found here - https://www.microsoft.com/technet/solutionaccelerators/cits/mo/smc/sts05.mspx.  The prescriptive guidance provided in this SA is still very relevant and helpful, so please take a moment and check it out.
  7. When developing a custom management pack to monitor an in-house developed application or service, one recommendation I can make is consider disabling the performance collection monitors or rules by default.  This approach allows you to enable them via override one at a time to verify their configuration and avoid impacting the agent, management server, and the SQL Servers hosting the OperationsManager or the OperationsManagerDW databases (if you are leveraging the performance data for reports). 

I think this is a good start and I'll continue this topic tomorrow.  So stay tuned and for those of you who attended today's session, I hope you found it of value and I thank you for attending.  For those of you who were unable to, it will be available for on-demand viewing shortly, so you can access it here - https://www106.livemeeting.com/cc/mseventsbmo/view?id=1032379751&role=attend&pw=4611BEDB.  If there is a particular topic you would like me to go into greater detail on, please let me know and I'll will be happy to expand and post it here on my blog.

Thanks!