Identify orphaned agent properties

Detective investigating items under a magnifying glass

 

Back again, I’m going to ‘Identify orphaned agent properties’.  For instance, does an agent still show up under Windows Computer, or more classes, like Windows Operating System?  Typically we have handled this by using Holman’s purge blog.

 

 

 

Deleting and Purging data from the SCOM Database

 

 

First, my thanks to Kevin H, Mihai S from the SCOM PG, & Premier Support CSS, for their help.  Let’s begin the ‘Identify orphaned agent properties’ discussion with ‘how’.  First, how do you get an orphaned property?  Second, how to you resolve?

 

Some example scenarios

    1. Server rebuilt with same name.  New agent runs discovery, and creates new set of GUID’s in the database.
    2. The Monitoring Tab > Windows Computer view contains unhealthy <gray> server objects.  Upon further inspection, the server does NOT show up in the Administration > Agent Managed view.
    3. Custom management pack authoring extends the Windows Computer class, or others (via SDK or PowerShell)

 

‘Identify and resolve’ orphaned agent properties

 

    1. Check for COMMIT or Overrides in management packs

PG recommended looking at Windows Computer extended class properties, and Connector Framework discoveries.

Microsoft.EnterpriseManagement.ConnectorFramework.IncrementalDiscoveryData.Commit()

or

Microsoft.EnterpriseManagement.ConnectorFramework.IncrementalDiscoveryData.Override()

 

Search for the ConnectorFramework

Search management packs (MP) via SCOM OpsDB (OperationsManager Database)

    1. Login to your SCOM OpsDB > New Query

select MPName, convert(xml, MPXML)

from ManagementPack

where

   MPXML like ‘%Commit(%’ or

   MPXML like ‘%Override(%’

Export management pack output or snag it/snippet screenshot

Example Snapshot from SQL query

SQL Query output of Management Pack output with Commit or Override
SQL query of MP Commit or Override pack matches

FYI – mgmt packs above use %Commit(%, but not the connectorFramework

 

Correct discoveries that use ConnectorFramework

Replace Discoveries

Update discoveries that contain:

New-Object Microsoft.EnterpriseManagement.ConnectorFramework.IncrementalDiscoveryData.Commit()

New-Object Microsoft.EnterpriseManagement.ConnectorFramework.IncrementalDiscoveryData.Override()

Replace with:

New-Object -comObject MOM.ScriptAPI for discovery

 

Test discoveries that use Remove method

Microsoft.EnterpriseManagement.ConnectorFramework.IncrementalDiscoveryData.Remove()

 

 

 

Example management pack discovery script

Contains

$discovery = New-Object Microsoft.EnterpriseManagement.ConnectorFramework.IncrementalDiscoveryData

$discovery.RemoveInternal($Instance,$ClassInstance.GetClasses()[0])

$discovery.Commit($mg)  <– This is the offender that causes the orphans

}

 

SQL on Windows Addendum pack

It’s spring time; time to tune the SQL carb!

 

Carbs are way less easy to find these days, but I’ve been busy tuning the SQL agnostic pack (MSSQL on Windows).

 

Tuning the SQL Agnostic pack would be far less successful without expert help.  My thanks to Brandon Pires – MCS SQL Consultant who helped provide a SQL DBA perspective.   Brandon’s LinkedIn profile

 

Always grab an expert, and for SQL, it’s a DBA.  If you’re new to SCOM, most product teams provide their management packs.  SCOM PFE’s build addendum packs to improve a pack (from our perspective).  Addendum packs make the a pack stronger, for an improved customer experience.  I’m not complaining at what the pack delivers.  The SQL Team is awesome for taking user feedback and making improvements quarterly!

 

Background:

Initially this journey started out with Tim McFadden disabling the duplicate rules/monitors in the SQL MP’s (here).

After talking with Tim and Kevin H, I set out to clean up the SQL version specific packs to remove bloat by creating the version specific OFF packs.  The OFF packs disabled the plethora of SQL performance counters (see MP bloat blog here).

With the SQL Agnostic packs (thank God!), I wanted to deliver an addendum pack to tune the SQL alerts/health for what SQL PFE/Consultants recommended for an improved out of the box experience (OoBE).

 

 

MP Version history
v1.0.0.0 24 Feb 2020 Override to enable SQL Monitoring
v1.0.0.1 24 Feb 2020 Override pack cleanup to human readable format
v1.0.0.2  2 Mar 2020 Overrides for severities and SQL CPU samples
v1.0.0.3  2 Mar 2020 Overrides for SQL rules for warning
v1.0.0.4  4 Mar 2020 Completed overrides for SQL warning rules

v1.0.0.5  1 Apr 2020 Updated rules for backup failures when customer uses Netbackup vs. SQL agent/scheduled tasks

v1.0.0.6  9 Apr 2020 Created groups for seed discovery Test/Dev and Prod; excluded EXPRESS, disabled Securables monitor

v1.0.0.7 15 Apr 2020 Updated pack name to include ‘SQL Server’.

Updated AddendumGroupGUIDUpdate to include RegEx pattern replace
AddendumGroupGUIDUpdate will version pack to v1.0.0.7 for group GUID and regex changes

 

 

Please feel free to download the zip file, which includes the XLS for review of what was updated.

My website download

 

 

Additional References

The Agnostic OFF Pack to turn off the performance rules (found here)

The old SQL version specific OFF packs for the performance counters can be found here.

TechNet Gallery download here

 

UNIX Logical Disk classes

Time to talk about SCOM2019 UNIX classes!

 

 

Just came across an example where the UNIX Logical disk class was targeted.

 

Did you know: This class in the UNIX library is not like the Windows library, where Logical Disk has a matched discovery.

Logical Disk is broke out to the various UNIX flavors, where the version of UNIX has it’s own class and discovery, but the class refers to the base class of UNIX Library.

 

Let’s go through an example from the SCOM Console

Monitoring Tab > Discovered Inventory > Change Target Type

 

This lab example is for an Ubuntu (Universal Linux Library)

The Logical Disk target for the UNIX/Linux Core Library has the same output in SCOM for the flavor (i.e. Logical Disk for the Universal Linux Operating System)

 

 

How’s that possible… ?

Let’s look at the examples for the various Logical Disk Classes.

Example

AIX 7 pack – AIX Logical disk discovery/class

<ClassType ID=”Microsoft.AIX.LogicalDisk” Abstract=”true” Accessibility=”Public” Hosted=”true” Singleton=”false” Base=”Unix!Microsoft.Unix.LogicalDisk” />

Universal Linux Monitoring Library

<ClassType ID=”Microsoft.Linux.Universal.LogicalDisk” Accessibility=”Public” Abstract=”false” Base=”Linux!Microsoft.Linux.LogicalDisk” Hosted=”true” Singleton=”false” Extension=”false” />

Linux Operating System Library

<ClassType ID=”Microsoft.Linux.LogicalDisk” Accessibility=”Public” Abstract=”true” Base=”Unix!Microsoft.Unix.LogicalDisk” Hosted=”true” Singleton=”false” Extension=”false” />

 

This makes sense, as Linux operating systems are SUSE, RHEL, Universal Debian and RPM.  Solaris and AIX are their own operating systems.  This helps describe the class hierarchy.

UNIX

Flavor of Unix (Linux, Solaris, or AIX)

Version or flavor of Linux, Solaris, or AIX

 

 

How did I get to this conclusion?

MPViewer will help view the classes and discoveries.

What does this mean to me:    Create a single view to view ALL  UNIX ‘Logical Disk’ entries discovered.  As the UNIX flavors all use UNIX Logical Disk class for their base class,  ALL the inherited classes are displayed.

 

 

AIX Logical Disk Discovery

 

Univeral Linux Discovery

Universal Linux Classes

 

Windows Server packs are very similar

Windows Logical Disk class