Watch Those Variant Types

When creating some types of Unit Monitors (such as SNMP polls) in the OpsMgr GUI, SCOM will set the default type of the values in the expressions to be strings.   If your health monitoring logic performs numerical comparisons, this will create unexpected and unreliable results, because the monitor will be performing comparisons on the numbers as strings, instead of as numerical data (if the system believes the values are strings, greater than and less than operators are concerned with alphabetical order, and not numerical comparisions).

The good news is that the fix is rather easy, just export the management pack, edit the type definitions in the XML file, and import it back.

For more details:

Read more of this post

“Must Have” SCOM Monitors – Long Running SQL Block Detection

Marios Philippopoulos did a great job  with an article on monitoring long-running SQL blocks with SCOM 2007 at SQLServerCentral.com.    The article:  Monitoring Database Blocking Through SCOM 2007 Custom Rules and Alerts (http://www.sqlservercentral.com/articles/Blocking/64038/)  provides a set of scripts for detecting (and display vital information about) long-running blocks in SQL Server 2000 and 2005 as well as a walkthrough on configuring the SCOM elements for alerting.  This is an absolute life-saver and can really cut down on troubleshooting time when dealing with application issues caused by problematic SQL blocking.

The only customizations I’ve made to this monitoring configuration when implementing are some changes to the SQL script to tune the block duration threshold as well as increase the size of some of the type definitions in the temp table to allow for longer command name output.

I’d highly recommend this article to anyone using SCOM to monitor SQL Server.

SCOM PowerShell Script for Maintenance Mode by IP address match

The web seems to bring us a seemingly endless supply of PowerShell scripts for manipulating maintenance mode in SCOM 2007.   I had occasion to write yet another maintenance mode script recently and thought it may be worth throwing out there.   This one will put objects (Windows Servers) in maintenance mode when the agent IP address matches a string.  This script can be useful to schedule maintenance mode when a remote site will be taken down for maintenance or patching.

#Connect to the RMS server and initialize the command shell
$rmsServerName=”<SERVERNAME>”
add-pssnapin “Microsoft.EnterpriseManagement.OperationsManager.Client”;
Set-Location “OperationsManagerMonitoring::”;
$mgConn = New-ManagementGroupConnection -connectionString:$rmsServerName;
if($mgConn -eq $null)
{
 [String]::Format(“Failed to connect to RMS on ‘{0}'”,$rmsServerName);
 return;
}
Set-Location $rmsServerName;

#Set up maintenance mode variables
$time = [DateTime]::Now
$nMinutes=1440

$class=get-monitoringclass | where {$_.displayname -eq “Windows Server”}

Function StartMM($agent){
 $objMon=get-monitoringobject -ID $agent.id
 write-host “Starting Maintenance Mode for: ” $objMon.displayname
 New-MaintenanceWindow -MonitoringObject $objMon -Comment “Suppressing IP network with a script” -StartTime $time -EndTime $time.AddMinutes($nMinutes)
}

get-agent |where {$_.IPAddress -like “192.168.1.*”} | ForEach-Object   {StartMM $_}
get-agent |where {$_.IPAddress -like “192.168.2.*”} | ForEach-Object   {StartMM $_}

To end maintenance mode, just a few slight modifications to the main body of the script:

#Set up maintenance mode variables
$time = [DateTime]::Now.AddMinutes(3)
write-host $time
$time = [DateTime]::Now.AddMinutes(5)

$class=get-monitoringclass | where {$_.displayname -eq “Windows Server”}

Function EndMM($agent){
 $objMon=get-monitoringobject -ID $agent.id
 write-host “Ending Maintenance Mode for: ” $objMon.displayname
  Set-maintenancewindow -EndTime $time -monitoringobject $objmon
}

get-agent |where {$_.IPAddress -like “192.168.1.*”} | ForEach-Object   {EndMM $_}
get-agent |where {$_.IPAddress -like “192.168.2.*”} | ForEach-Object   {EndMM $_}

A creative use for this script behind the cut:

Read more of this post

Selectively Generating Helpdesk Tickets from the SCOM Console – Using Resolution States

Many organizations have some form of an audit requirement that critical alerts from a monitoring system are mapped to helpdesk tickets for tracking. While the simplest solution would be a configuration that generated helpdesk tickets (with an email or script) for every critical alert fired, this is not always practical. Examples of this problem are easy to think of: if connectivity is lost to a remote site, many alerts (system and network) may be generated, but only one helpdesk ticket should be generated; or in SCOM-monitored environments, if an administrator reboots a cluster node and doesn’t put the cluster in maintenance mode, or a threshold monitor (e.g. SQL database free space) is floating just above and below the threshold repeatedly, many alerts can be generated, but not all should translate to helpdesk tickets.

This scenario leads to three possible outcomes: 1) superfluous helpdesk tickets are created with full automation, 2) no tickets are created (no automation), or 3) tickets are manually created after review of the alerts by an operator. Obviously, the latter option is more desirable than creating no tickets and is likely to be more desirable than creating too many tickets. If opting for the manual ticket creation option, it is very easy in SCOM to use custom Resolution States to facilitate manual ticket creation from within the SCOM console (an alert console task could also be used, but the resolution state option is much easier), thus creating a partially automated solution.

 When the resolution state of an alert is changed, SCOM reanalyzes the notification subscriptions and will trigger notification subscriptions that match the new resolution state. So, by adding a custom resolution state (perhaps named: “Create HelpDesk Ticket”) a new notification subscription can be added (filtered to this resolution state) in order to fire a different response than the original subscription that responded to the “New” resolution state. With this configuration, any SCOM operator can simply set the resolution state in the SCOM console and let the notifications take it from there. If your helpdesk system doesn’t listen for inbound email messages, a SCOM command notification could be used in the same way to fire a script or executable that creates the helpdesk ticket.

Walkthrough: Read more of this post