Some months ago Cisco released a brand new management pack for the UCS hardware platform, this update was more or less a rewrite of the entire solution, including switching all alarms from monitor based to rule based. This was done in order to minimize the number of discoveries needed and therefor the objects created by the management pack, this could have quite a performance impact since every little memory module and fan was discovered as objects, and this could be many fans and memory blocks in a large UCS environment.

Since it is all rule based now we would miss the auto-resolve feature usually used by monitors, but to solve this Cisco created a rule using a simple schedule to close and update alerts as needed based on the event entries on the server running the Cisco UCS monitoring service. But with the first release (4.0.1) there was a problems, it was only checking for alerts with resolution state New (0) and i guess in most production environments many are using resolution states to route alerts to correct teams or set the progress of the alert, therefor when you changed resolution state on your alerts they would never update or close. This problem is now solved in version 4.1.1 but now a new problem appears! Cisco choose to use “Where-Object {$_.ResolutionState -ne 255” to find all the non-closed alerts, using this method in our large environment it takes 10-12 seconds to find all the closed alerts and to make it even worse this command is running for every event collected by the rule “Cisco.Ucs.Watcher.UCSFault.Event.Collection.Rule” for the selected interval meaning that the script would never complete in our case and end on timeout.

To resolve all this I found all the elements needed for the rule “Cisco.Ucs.Library.UpdateAndCloseAlert.Rule” in the original Cisco Management pack and created my own fix for this problem.

Instead of

$scomActiveAlerts = Get-SCOMAlert | Where-Object {$_.ResolutionState -ne 255}

I changed it to

$ActiveAlerts = Get-SCOMAlert -ResolutionState (0..254)

This simple change gives the same result but in 0,5 seconds instead of 10-12. And instead of running the command for each event collected I changed it to run one time for the script (just before the ForEach) and save the result in a variable $ActiveAlerts and use that in the ForEach instead.

This just shows how easy you can improve (and decrease) the performance of your PowerShell scripts.

I uploaded my fix management pack to GitHub, if you import this one remember to disable the original rule.

GitHub Download

I recently did some house keeping in our OpsMgr environment, cleaning up old and unused Management Packs, and to easily identify potential unused Management Packs I of course turned to PowerShell!

This script can walk through the management packs and get the number of instances for each class. If there is no instances of a class it is very likely that it is not used. After running this script you will end up with a list of potential unused classes, you can now check each management pack for it’s content and see if there is other classes in it that is in use.

################################################################
#   Author: Andreas Sobczyk, CloudMechanic.net
#
#   Get Empty classes from Management Packs
################################################################

## Get all management packs starting with Contoso.
$MPs = Get-SCOMManagementPack -name Contoso*

## For each MP, For each Class, count classinstances.
$Overview = @()
Foreach($MP in $MPs){
$Classes = $mp.GetClasses()

foreach($Class in $Classes){
$ClassInstance = $null
$ClassInstance = Get-SCOMClassInstance -Class $class

## If you want you can change the number of class instances to sort on.
if($ClassInstance.Count -le 0){
$Overview += $Class
}
}
}

$Overview | Format-Table Name,Displayname,ManagementpackName

GitHub Download