Matt Goedtel on Operations Management : Tools

Updated PowerShell Script - Maintenance Mode

mgoedtel — Thu, 29 Oct 2009 18:22:00 GMT

I was recently e-mailed by a colleague regarding the maintenance mode PowerShell script that was originally released by Boris Yanushpolsky (found here) that worked great for RTM/SP1, but was failing when executed on an OpsMgr 2007 R2 agent managed system. In addition, the script was designed to place an object into maintenance mode for an hourly duration, not in minutes matching the setting in the Operations Console.

As you know, in Operations Manager RTM/SP1, we did not place the health service or health service watcher instance of the computer object into maintenance mode as one would expect, when you place a computer and its contained objects into maintenance mode. In Operations Manager R2, this was resolved and no longer requires you to perform this as a second step in the process.

The attached script has been updated to support automating the placement of computer objects into maintenance mode for Operations Manager R2, and now accepts the argument of minutes instead of hours for duration of maintenance. I am also in the process of updating the Maintenance Mode management pack that Brian Wren originally developed, and Andrzej Lipka (a former MCS Consultant from Poland) and myself modified with some additional features (see Andrzej's MP here and mine here) so you can leverage it for R2. I hope to have it completed and tested by this weekend, and submitted for review and release on http://www.opsmanjam.com the following week.

The command-line for executing the script is:

Starting MM - powershell "c:\MMode_R2.ps1" -groupName 'All Computers' -minutes 10 -rmsServerName RMSSERVER -startMM $true

Ending MM - powershell "c:\MMode_R2.ps1" -groupName 'All Computers' -minutes 10 -rmsServerName RMSSERVER -startMM $false

Suggestions and feedback are always welcome.

Follow-up from my MP Lifecycle Management TechNet Webcast

mgoedtel — Thu, 12 Jun 2008 05:33:00 GMT

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.

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 - http://blogs.msdn.com/boris_yanushpolsky/default.aspx. Those tools I mentioned were Override Explorer and Override Creator.
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 - http://blogs.msdn.com/boris_yanushpolsky/default.aspx. This tool is called MP Viewer.
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 - http://www.silect.com/solutions/opsmgr_Sol/opsmgr_Sol_studio.html.
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.
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.
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 - http://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.
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!

A Cool Tool for your Operations Manager Toolkit - PowerGUI

mgoedtel — Thu, 27 Mar 2008 03:36:00 GMT

So I came across this a week or so ago but forgot to install and play with it until today. PowerGUI is a freeware product from Quest that provides an IDE for working with PowerShell on your systems, and has integration with Operations Manager 2007, in addition to Active Directory and Exchange Server 2007. I just started to poke around with it on my Management Server, and it is actually pretty cool because it can help you in learning how to leverage the power of PowerShell integration in managing your Operations Manager environment. Coding in PowerShell is one area I have not been able to devote enough time to, but I see how this tool can somewhat reduce that learning curve.

It is a bit basic, but it's a start and the developer is looking to provide additional features in the near future.

You can learn more about it and download it from here - http://www.powergui.org/index.jspa