Tuesday, July 31, 2012

IBM Hardware MP for IBM BladeCenter and System x

IBM has released (very silently) the new Management Pack for SCOM 2012.

Features include:

  • Support Microsoft System Center Operations Manager 2012
  • Extensive monitoring of the health of hardware components for IBM System x servers and BladeCenter x86/x64 blades running Windows
  • Rich monitoring of the health of BladeCenter chassis and BladeCenter modules via the SNMP protocol
  • Comprehensive monitoring of the health of software stacks for managing IBM hardware
  • Easy determination
  • Power Monitoring of UEFI/IMM System X Servers and Blades running Windows 2008 & R2. Offers the ability to monitor overall system power usage, and generates alerts when power consumption rises above predefined consumption thresholds
  • BladeCenter and Blade hardware health correlation and event propagation providing BladeCenter specific hardware health condition monitoring under the Windows health explorer view.
  • Remote power on and off of Blades Servers via the Operations Manager console.
  • Hardware Management Software Configuration Advisor for IBM Systems detects the presence of IBM Hardware MP software dependencies in order to make appropriate configuration recommendations.
  • Set custom power consumption thresholds for Power Monitoring alerts via Operations Manager Agent task
  • Enable Power Capping and set the maximum power consumption wattage via Operation Manage Agent task

You can download the Installation Files, Release Notes and Guide from the following URL:

http://www-947.ibm.com/support/entry/portal/docdisplay?lndocid=migr-5082204

The release notes and the guide as well are well documented. So I recommend to read that stuff first!

All information is provided "as is" without any warranty! Try in lab before. Handle with care in production.

Read Full Post...

Tuesday, July 24, 2012

PowerShell: show Property Bag data

Of course this is not rocket science but  thought this might still be useful when developing or troubleshooting a Management Pack with PowerShell modules:

Your script body usually looks like this:

<ScriptBody>
  <![CDATA[
  # Always use the param statement to access parameters
  param($myArg1)
             
  # Get access to the scripting API
  $API = new-object -comObject "MOM.ScriptAPI"
  # Create the property bag
  $BAG = $API.CreatePropertyBag()
  # Do your magic script stuff here
  # Populate the property bag with data
  $BAG.AddValue("State","Healthy")
  $BAG
  ]]>
</ScriptBody>

The “problem” here is that if you run your script directly in PowerShell for troubleshooting you’d always get “System.__ComObject”.


After adding the following line to your script you’ll get the XML data that has been added to the property bag:

$API.Return($BAG)
Not a big thing but helpful at all…

All information is provided "as is" without any warranty! Try in lab before. Handle with care in production.

Read Full Post...

PowerShell Modules & Parameters

Last week I created an advanced Management Pack for a customer to monitor their VMware environment [1]. To achieve their needs the VMware admin created the PowerCLI (PowerShell with VMware Snap Ins) scripts and provided them to me. My part of the task was to implement the scripts into SCOM PowerShell workflows.

There is a real good guide for creating a PowerShell workflow by our friend Stefan Koell so it is not necessary to invent the wheel again. You’ll find all parts of the blog here, here, here and here.

So I created the MP and imported it into my MG but unfortunately it did not run as expected. After some troubleshooting (that was hard, even in the traces I was not able to find the issue) I found out that the parameters from the MP itself were not given to the scripts.

After reviewing the scripts I realized that there was a very simple part missing: The script author used $args variable instead of declaring the parameters.

So after declaring them by adding

Param(
  [string]$firstargument,
  [int]$secondargument,
  [string]$thirdargument
)

and replacing the $args[…] by the variables declared before everything worked as expected.


That was easy but still tricky to troubleshoot…


[1] There are 3rd Party solutions from our partners available. You’ll find them here.


All information is provided "as is" without any warranty! Try in lab before. Handle with care in production.

Read Full Post...