Menu Close

Extending UNIX/Linux Computer class from a local file



I recently wrote a blog article on Extending the Windows Computer class from Registry keys on agents.  You can read about that here:

However, what about UNIX/Linux agents?  They don’t have the concept of a Windows Registry.  For those, we can use a file on the file system as an example.


In this example – we create a new class, “DemoFile.UNIX.Computer.Extended.Class”

We use Microsoft.Unix.Computer as the base class, and we will add three example properties:  TIER, GROUPID, and OWNER.


<ClassType ID="DemoFile.UNIX.Computer.Extended.Class" Accessibility="Public" Abstract="false" Base="Unix!Microsoft.Unix.Computer" Hosted="false" Singleton="false" Extension="false"> <Property ID="TIER" Type="string" AutoIncrement="false" Key="false" CaseSensitive="false" MaxLength="256" MinLength="0" Required="false" Scale="0" /> <Property ID="GROUPID" Type="string" AutoIncrement="false" Key="false" CaseSensitive="false" MaxLength="256" MinLength="0" Required="false" Scale="0" /> <Property ID="OWNER" Type="string" AutoIncrement="false" Key="false" CaseSensitive="false" MaxLength="256" MinLength="0" Required="false" Scale="0" /> </ClassType>


We will use a file on the filesystem to contain the properties in order.  This will allow individual business units to control their own class properties for grouping purposes.

We will name the file “scom.conf” and place it in /opt/microsoft/ directory

This discovery will discover each custom class property you want, using the three examples above.  My file looks like the following:



In order to discover properties in UNIX/Linux, it is a bit more complicated than under Windows.  We need a discovery, that will call a Command Shell datasource, that will then pass the output (StdOut) to a PowerShell script.  The PowerShell script can then take the comma delimited data, and split it out into individual class properties to add to the discovery.  The last step of the PowerShell script is to output the discovery data.  With UNIX/Linux systems in SCOM – all the workflows run against the management servers, so PowerShell is a perfect option.

Here is the PowerShell discovery script:

param($SourceId,$ManagedEntityId,$TargetSystem,$StdOut) # For testing discovery manually in PowerShell: # $SourceId = '{00000000-0000-0000-0000-000000000000}' # $ManagedEntityId = '{00000000-0000-0000-0000-000000000000}' # $StdOut = "2,LINUX,kevinhol" # $TargetSystem = "" #================================================================================= # Constants section - modify stuff here: # Assign script name variable for use in event logging $ScriptName = "DemoFile.UNIX.Computer.Extended.Class.Discovery.Datasource.ps1" #================================================================================= # Gather script start time $StartTime = Get-Date # Gather who the script is running as $WhoAmI = whoami # Load MOMScript API $momapi = New-Object -comObject MOM.ScriptAPI # Load SCOM Discovery module $DiscoveryData = $momapi.CreateDiscoveryData(0, $SourceId, $ManagedEntityId) # Log an event for the script starting $momapi.LogScriptEvent($ScriptName,6666,0, "Script is starting. UNIX Computer: ($TargetSystem) StdOut: ($StdOut) Running, as $WhoAmI.") # Clear any previous errors if($Error) { $Error.Clear() } #================================================================================= # MAIN body of your script if($StdOut -ne $null -and $StdOut -ne "0" -and $StdOut -ne "") { # $StdOut = $CmdOutput.Replace([Environment]::newline,":") $Properties = $StdOut.Split(",") $TIER = $Properties[0] $GROUPID = $Properties[1] $OWNER = $Properties[2] # Create discovery data $Inst = $DiscoveryData.CreateClassInstance("$MPElement[Name='DemoFile.UNIX.Computer.Extended.Class']$") $Inst.AddProperty("$MPElement[Name='Unix!Microsoft.Unix.Computer']/PrincipalName$", $TargetSystem) $Inst.AddProperty("$MPElement[Name='DemoFile.UNIX.Computer.Extended.Class']/TIER$", $TIER) $Inst.AddProperty("$MPElement[Name='DemoFile.UNIX.Computer.Extended.Class']/GROUPID$", $GROUPID) $Inst.AddProperty("$MPElement[Name='DemoFile.UNIX.Computer.Extended.Class']/OWNER$", $OWNER) $DiscoveryData.AddInstance($Inst) #================================================================================= # Return Discovery Items Normally $DiscoveryData # Return Discovery Bag to the command line for testing (does not work from ISE): # $momapi.Return($DiscoveryData) } Else { # Log an event the StdOut was NULL $momapi.LogScriptEvent($ScriptName,6667,2, "StdOut was NULL. Did not get any data from UNIX Shell Command") } # End script and record total runtime $EndTime = Get-Date $ScriptTime = ($EndTime - $StartTime).TotalSeconds # Log an event for script ending and total execution time. $momapi.LogScriptEvent($ScriptName,6666,0, "Script has completed. Runtime was $ScriptTime seconds")


When I review Discovered Inventory in the console for this class, I can see the properties:





I am attaching the sample MP file at the following location:


    • Kevin Holman

      Because when we chose an existing base class, we inherit all properties, and monitoring, of the base class. This is by design. Also why we must choose existing base classes carefully, and why most custom classes should use LocalApplication or ApplicationComponent base classes because they don’t have any properties or monitoring.

  1. Ehud


    I changed it to : Base=”Unix!Microsoft.Unix.LocalApplication”
    But again, it is still monitored by default . . . .

    My goal is to get “Clean” unmonitored object (as I do with Windows server).

  2. Ehud


    When I configuring a new registry discovery (Windows), I’m doing it with MP Author. A
    For example, the discovery find each servers that their HOSTNAME starts with “A*”
    Also I configuring a base class as Local Windows application.
    Let say the this class called “The A servers”
    Then I check the Discovery Inventory, and I can see list of all the servers that stars with A,
    But all of them are not monitored. And this is good for me because I want to attach a new monitor – to this target -“The A servers”.

    The main purpose is to obtain a pure state status of this specific monitor, and use it as a component inside DA.

    But it is not working with the Linux servers, also when I’m using : Base=”Unix!Microsoft.Unix.LocalApplication”

    Thanks, Ehud

  3. Ehud


    Just to make it clear – When I’m saying “But it is not working with the Linux servers” It means that default monitors are rolling up (for example CPU, RAM, etc).
    And this is not the behavior I need 🙂

Leave a Reply

Your email address will not be published.