Monthly Archives: February 2014

SCOM 2012: NiCE Logfile Monitoring Management Pack

Now as some of you may know out of the box SCOM capabilities to monitor log files can fall a bit short under certain circumstances. Luckily a company called NiCE, which has also developed management pack solutions for applications such as Oracle, SAP, DB2 and others, is releasing a full featured Log File MP to the community and best of all it’s FREE.

image112

Here is a comparison between the Native SCOM capabilities and the enhancements offered by the NiCE Log File MP.

comparison2This is a feature rich management pack offering a range of custom rules and monitors which also cater for log line correlation and preprocessing scenarios as well as customizable alerting and behavior for when a log file is missing or does not exist.

Stefan Roth has already written a nice review of some of the management pack capabilities: here using a custom monitor with a robocopy log file to determine when copies have failed.

The free Log File management pack is available for download from http://www.nice.de

SCOM: Upgrade to Operations Manager 2012 R2 may result in Data Warehouse synchronization failures

Brian McDermott highlighted an issue to watch out for when upgrading to SCOM 2012 R2 where you may get Data Warehouse synchronization failure errors after the upgrade.

The article can be found here with solid reasoning as to the cause and solution:

Please note that the Event ID 31565 noted above is a very generic error and you should only run the SQL below if the description identifies that it is the problem with the TFSWorkItemID column.

Error below:

Log Name:      Operations Manager
Source:        Health Service Modules
Date:
Event ID:      31565
Task Category: Data Warehouse
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      OMMS.domain.com
Description:
Failed to deploy Data Warehouse component. The operation will be retried.
Exception ‘DeploymentException’: Failed to perform Data Warehouse component deployment operation: Install; Component: DataSet, Id: ‘0d698dff-9b7e-24d1-8a74-4657b86a59f8′, Management Pack Version-dependent Id: ’29a3dd22-8645-bae5-e255-9b56bf0b12a8′; Target: DataSet, Id: ’23ee52b1-51fb-469b-ab18-e6b4be37ab35’. Batch ordinal: 3; Exception: Sql execution failed. Error 207, Level 16, State 1, Procedure vAlertDetail, Line 18, Message: Invalid column name ‘TfsWorkItemId’.

This issue can be fixed with the below SQL query, as always BACKUP your databases and proceed at your own risk:
USE OperationsManagerDW
 
DECLARE @GuidString NVARCHAR(50)
SELECT @GuidString = DatasetId FROM StandardDataset
WHERE SchemaName = ‘Alert’
 
— update all tables that were already created
DECLARE
   @StandardDatasetTableMapRowId int
  ,@Statement nvarchar(max)
  ,@SchemaName sysname
  ,@TableNameSuffix sysname
  ,@BaseTableName sysname
  ,@FullTableName sysname
 
SET @StandardDatasetTableMapRowId = 0
 
WHILE EXISTS (SELECT *
              FROM StandardDatasetTableMap tm
              WHERE (tm.StandardDatasetTableMapRowId > @StandardDatasetTableMapRowId)
                AND (tm.DatasetId = @GuidString)
             )
BEGIN
  SELECT TOP 1
     @StandardDatasetTableMapRowId = tm.StandardDatasetTableMapRowId
    ,@SchemaName = sd.SchemaName
    ,@TableNameSuffix = tm.TableNameSuffix
    ,@BaseTableName = sdas.BaseTableName
  FROM StandardDatasetTableMap tm
          JOIN StandardDataset sd ON (tm.DatasetId = sd.DatasetId)
          JOIN StandardDatasetAggregationStorage sdas ON (sdas.DatasetId = tm.DatasetId) AND (sdas.AggregationTypeId = tm.AggregationTypeId)
  WHERE (tm.StandardDatasetTableMapRowId > @StandardDatasetTableMapRowId)
    AND (tm.DatasetId = @GUIDString)
    AND (sdas.TableTag = ‘detail’)
    AND (sdas.DependentTableInd = 1)
  ORDER BY tm.StandardDatasetTableMapRowId
 
  SET @FullTableName = @BaseTableName + ‘_’ + @TableNameSuffix
 
  IF NOT EXISTS (SELECT * FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = @FullTableName AND TABLE_SCHEMA = @SchemaName
    AND COLUMN_NAME = N’TfsWorkItemId’)
  BEGIN
    SET @Statement = ‘ALTER TABLE ‘ + QUOTENAME(@SchemaName) + ‘.’ + QUOTENAME(@FullTableName) + ‘ ADD TfsWorkItemId nvarchar(256) NULL’
    EXECUTE (@Statement)
  END
 
  IF NOT EXISTS (SELECT * FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = @FullTableName AND TABLE_SCHEMA = @SchemaName
    AND COLUMN_NAME = N’TfsWorkItemOwner’)
  BEGIN
    SET @Statement = ‘ALTER TABLE ‘ + QUOTENAME(@SchemaName) + ‘.’ + QUOTENAME(@FullTableName) + ‘ ADD TfsWorkItemOwner nvarchar(256) NULL’
    EXECUTE (@Statement)
  END
END
 
— alter cover views
EXEC StandardDatasetBuildCoverView@GUIDString, 0
GO

 

SCOM 2012: Web based Maintenance Mode Tool

A new web based maintenance mode tool has been released by Tim McFadden and is available for purchase here (with a 30 day free trial)

From the site “The new web based scheduler simplifies the process of scheduling maintenance mode for SCOM administrators and IT staff.  You can easily schedule a computer group or any object to maintenance mode in seconds.”

The tool looks very polished and comprised a web based interface as well as a windows 8 app. There is also a really nice feature included which allows a shortcut to be placed on any server desktop which when used will place that specific server into maintenance, now that’s cool.

Cost:
Site License with one year free updates $99

Site License with two years free updates $149

SCOM 2012: Enable agent proxy on all agents

Kevin Holman has posted a couple of powershell scripts to simplify enabling proxy for SCOM 2012 agents, proxy always on is a particularly handy find:

Turn on agent proxy for all agents where it is disabled:
get-SCOMagent | where {$_.ProxyingEnabled -match “False”} | Enable-SCOMAgentProxy

Turn on agent proxy as a default setting for all new agents to be deployed, never to have to mess with this again:
add-pssnapin “Microsoft.EnterpriseManagement.OperationsManager.Client”; new-managementGroupConnection -ConnectionString:scomserver.domain.com; set-location “OperationsManagerMonitoring::”; Set-DefaultSetting -Name HealthService\ProxyingEnabled -Value True

SCOM: When updating the IBM Storage Management Pack to 2.1.0

When updating the IBM Storage Management Pack to 2.1.0 there are a few things to be aware of, most of which is included in the documentation.

After completing the installation, running the upgrade configuration and removing the old management packs and importing the new ones we still weren’t able to re-discover the IBM SAN.

The documentation recommends, in the configuration section that, “The IBM storage configuration must be synchronized with Management Server manually  if there is storage configuration left after upgrading from previous version to version 2.1.0. The IBM storage configuration also should be synchronized with the Management Server manually after the management pack is deleted and re-imported.”

Except that the command skipped all of our SANs.

IMB1

Checking the SCOM configuration revealed that something which shouldn’t have happened, had happened. The SCOM configuration had been lost during the upgrade

IMB2

Using the –sc-set command to re-do the configration was successful, which allowed the migration to complete and in short order the SANs were discovered and monitoring.

IMB3