Years ago – I wrote a post on this, showing how to use registry keys to add properties to the “Windows Computer” class, to make creating custom groups much simpler.  You can read about the details of how and why here:  https://blogs.technet.microsoft.com/kevinholman/2009/06/10/creating-custom-dynamic-computer-groups-based-on-registry-keys-on-agents/\

This post is a simple updated example of that Management Pack, but written more “properly”.  You can use this example ad add/change your own registry keys for additional class properties.

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

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

  <TypeDefinitions>
    <EntityTypes>
      <ClassTypes>
        <ClassType ID="DemoReg.Windows.Computer.Extended.Class" Accessibility="Public" Abstract="false" Base="Windows!Microsoft.Windows.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>
      </ClassTypes>
    </EntityTypes>
  </TypeDefinitions>

We will use a filtered registry discovery provider, where we filter the discovery based on finding the existence of “HKLM\SOFTWARE\Contoso” which would relate to your custom company RegKey.

In addition – this discovery will discover each custom class property you want, using the three examples above.  My registry looks like the following:

The discovery targets “Windows Server Operating System” this keeps it from creating duplicate discoveries based on clusters.  However, if you WANT to include cluster Windows Computer objects, you will need to change the target class to Microsoft.Windows.Computer (and remove the HOST from $Target/Host references in the discovery)

Here is the sample discovery:

  <Monitoring>
    <Discoveries>
      <Discovery ID="DemoReg.Windows.Computer.Extended.Class.Discovery" Target="Windows!Microsoft.Windows.Server.OperatingSystem" Enabled="true" ConfirmDelivery="false" Remotable="false" Priority="Normal">
        <Category>Discovery</Category>
        <DiscoveryTypes>
          <DiscoveryClass TypeID="DemoReg.Windows.Computer.Extended.Class">
            <Property TypeID="DemoReg.Windows.Computer.Extended.Class" PropertyID="TIER" />
            <Property TypeID="DemoReg.Windows.Computer.Extended.Class" PropertyID="GROUPID" />
            <Property TypeID="DemoReg.Windows.Computer.Extended.Class" PropertyID="OWNER" />
          </DiscoveryClass>
        </DiscoveryTypes>
        <DataSource ID="DS" TypeID="Windows!Microsoft.Windows.FilteredRegistryDiscoveryProvider">
          <ComputerName>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</ComputerName>
          <RegistryAttributeDefinitions>
            <RegistryAttributeDefinition>
              <AttributeName>ContosoExists</AttributeName>
              <Path>SOFTWARE\Contoso</Path>
              <PathType>0</PathType>
              <AttributeType>0</AttributeType>
            </RegistryAttributeDefinition>
            <RegistryAttributeDefinition>
              <AttributeName>TIER</AttributeName>
              <Path>SOFTWARE\Contoso\TIER</Path>
              <PathType>1</PathType>
              <AttributeType>1</AttributeType>
            </RegistryAttributeDefinition>
            <RegistryAttributeDefinition>
              <AttributeName>GROUPID</AttributeName>
              <Path>SOFTWARE\Contoso\GROUPID</Path>
              <PathType>1</PathType>
              <AttributeType>1</AttributeType>
            </RegistryAttributeDefinition>
            <RegistryAttributeDefinition>
              <AttributeName>OWNER</AttributeName>
              <Path>SOFTWARE\Contoso\OWNER</Path>
              <PathType>1</PathType>
              <AttributeType>1</AttributeType>
            </RegistryAttributeDefinition>
          </RegistryAttributeDefinitions>
          <Frequency>86400</Frequency>
          <ClassId>$MPElement[Name="DemoReg.Windows.Computer.Extended.Class"]$</ClassId>
          <InstanceSettings>
            <Settings>
              <Setting>
                <Name>$MPElement[Name="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Name>
                <Value>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Value>
              </Setting>
              <Setting>
                <Name>$MPElement[Name="DemoReg.Windows.Computer.Extended.Class"]/TIER$</Name>
                <Value>$Data/Values/TIER$</Value>
              </Setting>
              <Setting>
                <Name>$MPElement[Name="DemoReg.Windows.Computer.Extended.Class"]/GROUPID$</Name>
                <Value>$Data/Values/GROUPID$</Value>
              </Setting>
              <Setting>
                <Name>$MPElement[Name="DemoReg.Windows.Computer.Extended.Class"]/OWNER$</Name>
                <Value>$Data/Values/OWNER$</Value>
              </Setting>
            </Settings>
          </InstanceSettings>
          <Expression>
            <SimpleExpression>
              <ValueExpression>
                <XPathQuery Type="Boolean">Values/ContosoExists</XPathQuery>
              </ValueExpression>
              <Operator>Equal</Operator>
              <ValueExpression>
                <Value Type="Boolean">true</Value>
              </ValueExpression>
            </SimpleExpression>
          </Expression>
        </DataSource>
      </Discovery>
    </Discoveries>
  </Monitoring>

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

I am attaching the sample MP file, along with the registry file, at the following location:

https://gallery.technet.microsoft.com/Extend-Windows-Computer-71eeb649

Years ago – I wrote a post on customizing the “Windows Computer” class, showing how to use registry keys to add properties to the “Windows Computer” class, to make creating custom groups much simpler.  You can read about the details of how and why here:  https://blogs.technet.microsoft.com/kevinholman/2009/06/10/creating-custom-dynamic-computer-groups-based-on-registry-keys-on-agents/

I later updated that sample MP here:  https://blogs.technet.microsoft.com/kevinholman/2016/12/04/extending-windows-computer-class-from-registry-keys-in-scom/

However, I was recently at a customer, and they felt stamping reg keys on all their servers would be too much work.  Additionally, they didn’t have a CMDB, or Authoritative system that recovered all their computers, and their important properties.  In this case, they used a spreadsheet for that.  So, I recommended we use a CSV based on their spreadsheet, to pull back this data into SCOM, using the CSV file as the authoritative record for their servers.

Here is an example of the CSV:

We can write an extended class of Windows Computer, and a script based discovery to read in this CSV, and add each column as a class property in SCOM.

Here is the class definition:

  <TypeDefinitions>
    <EntityTypes>
      <ClassTypes>
        <ClassType ID="DemoCSV.Windows.Computer.Extended.Class" Accessibility="Public" Abstract="false" Base="Windows!Microsoft.Windows.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>
      </ClassTypes>
    </EntityTypes>
  </TypeDefinitions>

The discovery will target the “All Management Servers Resource Pool” class.  This class is hosted by ONE of the management servers at any given time, and by doing this we will have high availability for the discovery workflow.

The script will read the CSV file, get the FQDN of each row in the CSV, then compare that to a list of all computers in SCOM.  If the computer exists in SCOM, it will add the properties to the discovery.  There is a “constants” section in the script for you to change relevant information:

#===============================
# Constants section – modify stuff here:
$CSVPath = “\\server\share\serverlist.csv”

Here is the script:

#=================================================================================
# Extend Windows Computer class from CSV
#=================================================================================

Param($SourceId,$ManagedEntityId)

# For testing discovery manually in PowerShell:
# $SourceId = '{00000000-0000-0000-0000-000000000000}'
# $ManagedEntityId = '{00000000-0000-0000-0000-000000000000}'

#=================================================================================
# Constants section - modify stuff here:
$CSVPath = "\\server\share\serverlist.csv"

# Assign script name variable for use in event logging
$ScriptName = "DemoCSV.Windows.Computer.Extended.Class.Discovery.Script.ps1"
#=================================================================================


#=================================================================================
# function Is-ClassMember
# Purpose:  To ensure we only return discovery data for computers that
#           already exist in SCOM, otherwise it will be rejected    
# Arguments: 
#  -$InstanceDisplayName - The name of the object instance like 'servername.domain.com'
#==================================================================================
function Is-ClassMember
  {
  param($InstanceDisplayName)
  If ($InstanceDisplayName -in $ComputerNames)
    {
    $value = "True"
    }
  Else
    {
    $value = "False"
    }
  Return $value
  }
# End of function Is-ClassMember




# Gather script start time
$StartTime = Get-Date

$MServer = $env:COMPUTERNAME

# 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,7777,0, "Script is starting. Running, as $WhoAmI.")

# Clear any previous errors
if($Error)
  {
  $Error.Clear()
  }

# Import the OperationsManager module and connect to the management group
Try
  {
  $SCOMPowerShellKey = "HKLM:\SOFTWARE\Microsoft\System Center Operations Manager\12\Setup\Powershell\V2"
  $SCOMModulePath = Join-Path (Get-ItemProperty $SCOMPowerShellKey).InstallDirectory "OperationsManager"
  Import-module $SCOMModulePath
  }
Catch
  {
  $momapi.LogScriptEvent($ScriptName,7778,2, "Unable to load the OperationsManager module, Error is: $error")
  }
Try
  {
  New-DefaultManagementGroupConnection $MServer
  }
Catch
  {
  $momapi.LogScriptEvent($ScriptName,7778,2, "Unable to connect to the management server: $MServer.  Error when calling New-DefaultManagementGroupConnection.  Error is: $error")
  }


# Get all instances of a existing Windows Computer class
# We need this to check and make sure each computer in the CSV exists in SCOM or discvoery data will be rejected
  $WindowsComputers = Get-SCOMClass -DisplayName "Windows Computer" | Get-SCOMClassInstance
  $ComputerNames = $WindowsComputers.DisplayName
  $ComputerCount = $ComputerNames.count
# Log an event for command ending
  $momapi.LogScriptEvent($ScriptName,7777,0, "Get all Windows Computers has completed.  Returned $ComputerCount Windows Computers.")

# Clear any previous errors
if($Error)
  {
  $Error.Clear()
  }

#Test the CSV path and make sure we can read it:
  If (Test-Path $CSVPath)
    {
    # Log an event for CSV path good
    $momapi.LogScriptEvent($ScriptName,7777,0, "CSV file was found at $CSVPath")
    }
  Else
    {
    # Log an event for CSV path bad
    $momapi.LogScriptEvent($ScriptName,7778,2, "CSV file was NOT found at $CSVPath  This is a fatal script error, ending script.  Error is $Error")
    exit
    }

# Query the CSV file to get the servers and properties
  $CSVContents = Import-Csv $CSVPath

# Loop through the CSV and add discovery data for existing SCOM computers
  $i=0;
  foreach ($row in $CSVContents)
    {
    # Get the FQDN and assign it to a variable
    $FQDN = $row.FQDN

    #Check and see if the $FQDN value contains a computer that exists as a Windows Computer in SCOM
    $IsSCOMComputer = Is-ClassMember $FQDN
    If ($IsSCOMComputer -eq "True")
        {
        $i=$i+1
        # Get each property in your CSV and assign it to a variable
        $TIER = $row.TIER
        $GROUPID = $row.GROUPID
        $OWNER = $row.OWNER

        # Create discovery data for each computer that exists in both the CSV and SCOM
        $Inst = $DiscoveryData.CreateClassInstance("$MPElement[Name='DemoCSV.Windows.Computer.Extended.Class']$")
        $Inst.AddProperty("$MPElement[Name='Windows!Microsoft.Windows.Computer']/PrincipalName$", $FQDN)
        $Inst.AddProperty("$MPElement[Name='DemoCSV.Windows.Computer.Extended.Class']/TIER$", $TIER)
        $Inst.AddProperty("$MPElement[Name='DemoCSV.Windows.Computer.Extended.Class']/GROUPID$", $GROUPID)
        $Inst.AddProperty("$MPElement[Name='DemoCSV.Windows.Computer.Extended.Class']/OWNER$", $OWNER)
        $DiscoveryData.AddInstance($Inst)
        } #End If
    } #End foreach


# Return Discovery Items
  $DiscoveryData

# Return Discovery Bag to the command line for testing (does not work from ISE):
# $momapi.Return($DiscoveryData)

$CSVMatchComputerCount = $i
$CSVRowCount = $CSVContents.Count

# 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,7777,0, "Script has completed.  CSV returned $CSVRowCount computers.  SCOM returned $ComputerCount Computers.  Discovery returned $CSVMatchComputerCount matching computers from the CSV and SCOM.  Runtime was $ScriptTime seconds")

You will need to change the path of the script file, and make sure your management server action account has read permissions to the share and file.

You can review the discovery data in discovered inventory:

I also added rich logging to the script to understand what is happening:

Log Name:      Operations Manager
Source:        Health Service Script
Date:          12/4/2016 2:53:18 PM
Event ID:      7777
Level:         Information
Computer:      SCOMA1.opsmgr.net
Description:
DemoCSV.Windows.Computer.Extended.Class.Discovery.Script.ps1 : Script has completed.  CSV returned 5 computers.  SCOM returned 26 Computers.  Discovery returned 5 matching computers from the CSV and SCOM.  Runtime was 5.8906066 seconds

I am attaching the sample MP file, along with the sample CSV registry file, at the following location:

https://gallery.technet.microsoft.com/Extend-Windows-Computer-ed54075c

Years ago – I wrote a post on customizing the “Windows Computer” class, showing how to use registry keys to add properties to the “Windows Computer” class, to make creating custom groups much simpler.  You can read about the details of how and why here:  https://blogs.technet.microsoft.com/kevinholman/2009/06/10/creating-custom-dynamic-computer-groups-based-on-registry-keys-on-agents/

I later updated that sample MP here:  https://blogs.technet.microsoft.com/kevinholman/2016/12/04/extending-windows-computer-class-from-registry-keys-in-scom/

I also provided a sample of doing the same thing from a CSV file:  https://blogs.technet.microsoft.com/kevinholman/2016/12/04/extending-windows-computer-class-from-a-csv-file-in-scom/

This post will demonstrate how to extend the Windows Computer class using a SQL database (CMDB) as the source for the class properties.  This is incredibly useful if you have an authoritative record of all servers, and important properties that you would like to use for grouping in SCOM.

Here is an example of my test CMDB:

We can write an extended class of Windows Computer, and a script based discovery to read in these tables by sending a query to a SQL DB, and add each returned column as a class property in SCOM.

Here is the class definition:

  <TypeDefinitions>
    <EntityTypes>
      <ClassTypes>
        <ClassType ID="DemoCMDB.Windows.Computer.Extended.Class" Accessibility="Public" Abstract="false" Base="Windows!Microsoft.Windows.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>
      </ClassTypes>
    </EntityTypes>
  </TypeDefinitions>

The discovery will target the “All Management Servers Resource Pool” class.  This class is hosted by ONE of the management servers at any given time, and by doing this we will have high availability for the discovery workflow.

The script will read the SQL DB via query, get the FQDN of each row in the database, then compare that to a list of all computers in SCOM.  If the computer exists in SCOM, it will add the properties to the discovery.  There is a “constants” section in the script for you to change relevant information:

#======================================================
# Constants section – modify stuff here:
$SQLServer = “SQL2A.opsmgr.net”
$SQLDBName =  “CMDB”
$SqlQuery = “SELECT FQDN, TIER, GROUPID, OWNER FROM [dbo].[ServerList] ORDER BY FQDN”

Here is the script:

#=================================================================================
# Extend Windows Computer class from CMDB
#=================================================================================

Param($SourceId,$ManagedEntityId)

# For testing discovery manually in PowerShell:
# $SourceId = '{00000000-0000-0000-0000-000000000000}'
# $ManagedEntityId = '{00000000-0000-0000-0000-000000000000}'

#=================================================================================
# Constants section - modify stuff here:
$SQLServer = "SQL2A.opsmgr.net"
$SQLDBName =  "CMDB"
$SqlQuery = "SELECT FQDN, TIER, GROUPID, OWNER FROM [dbo].[ServerList] ORDER BY FQDN"

# Assign script name variable for use in event logging
$ScriptName = "DemoCMDB.Windows.Computer.Extended.Class.Discovery.Script.ps1"
#=================================================================================


#=================================================================================
# function Is-ClassMember
# Purpose:  To ensure we only return discvoery data for computers that
#     already exist in SCOM, otherwise it will be rejected    
# Arguments: 
#  -$InstanceDisplayName - The name of the object instance like 'servername.domain.com'
#==================================================================================
function Is-ClassMember
  {
  param($InstanceDisplayName)
  If ($InstanceDisplayName -in $ComputerNames)
    {
    $value = "True"
    }
  Else
    {
    $value = "False"
    }
  Return $value
  }
# End of function Is-ClassMember


# Gather script start time
$StartTime = Get-Date

$MServer = $env:COMPUTERNAME

# 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,8888,0, "Script is starting. Running, as $WhoAmI.")

# Clear any previous errors
if($Error)
  {
  $Error.Clear()
  }

# Import the OperationsManager module and connect to the management group
Try
  {
  $SCOMPowerShellKey = "HKLM:\SOFTWARE\Microsoft\System Center Operations Manager\12\Setup\Powershell\V2"
  $SCOMModulePath = Join-Path (Get-ItemProperty $SCOMPowerShellKey).InstallDirectory "OperationsManager"
  Import-module $SCOMModulePath
  }
Catch
  {
  $momapi.LogScriptEvent($ScriptName,8889,2, "Unable to load the OperationsManager module, Error is: $error")
  }
Try
  {
  New-DefaultManagementGroupConnection $MServer
  }
Catch
  {
  $momapi.LogScriptEvent($ScriptName,8889,2, "Unable to connect to the management server: $MServer.  Error when calling New-DefaultManagementGroupConnection.  Error is: $error")
  }


# Get all instances of a existing Windows Computer class
# We need this to check and make sure each computer in the CMDB exists in SCOM or discovery data will be rejected
  $WindowsComputers = Get-SCOMClass -DisplayName "Windows Computer" | Get-SCOMClassInstance
  $ComputerNames = $WindowsComputers.DisplayName
  $ComputerCount = $ComputerNames.count
# Log an event for command ending
  $momapi.LogScriptEvent($ScriptName,8888,0, "Get all Windows Computers has completed.  Returned $ComputerCount Windows Computers.")

# Clear any previous errors
if($Error)
  {
  $Error.Clear()
  }

# Query the CMDB database to get the servers and properties
  $SqlConnection = New-Object System.Data.SqlClient.SqlConnection
  $SqlConnection.ConnectionString = “Server=$SQLServer;Database=$SQLDBName;Integrated Security=True”
  $SqlCmd = New-Object System.Data.SqlClient.SqlCommand
  $SqlCmd.CommandText = $SqlQuery
  $SqlCmd.Connection = $SqlConnection
  $SqlAdapter = New-Object System.Data.SqlClient.SqlDataAdapter
  $SqlAdapter.SelectCommand = $SqlCmd
  $ds = New-Object System.Data.DataSet
  $SqlAdapter.Fill($ds)
  $SqlConnection.Close()

$i=0;
$j=0;
foreach ($row in $ds.Tables[0].Rows)
  {
  $i = $i+1
  $FQDN = $row[0].ToString().Trim()

  $IsSCOMComputer = Is-ClassMember $FQDN
  If($IsSCOMComputer -eq "True")
    {
    $j=$j+1
    $TIER = $row[1].ToString().Trim()
    $GROUPID = $row[2].ToString().Trim()
    $OWNER = $row[3].ToString().Trim()

    # Create discovery data for each computer that exists in both the CMDB and SCOM
    $Inst = $DiscoveryData.CreateClassInstance("$MPElement[Name='DemoCMDB.Windows.Computer.Extended.Class']$")
    $Inst.AddProperty("$MPElement[Name='Windows!Microsoft.Windows.Computer']/PrincipalName$", $FQDN)
    $Inst.AddProperty("$MPElement[Name='DemoCMDB.Windows.Computer.Extended.Class']/TIER$", $TIER)
    $Inst.AddProperty("$MPElement[Name='DemoCMDB.Windows.Computer.Extended.Class']/GROUPID$", $GROUPID)
    $Inst.AddProperty("$MPElement[Name='DemoCMDB.Windows.Computer.Extended.Class']/OWNER$", $OWNER)
    $DiscoveryData.AddInstance($Inst)
    } #End If
  } #End foreach

# Return Discovery Items
$DiscoveryData

# Return Discovery Bag to the command line for testing (does not work from ISE):
# $momapi.Return($DiscoveryData)

$CMDBMatchComputerCount = $j
$CMDBRowCount = $i

# 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,8888,0, "Script has completed.  CMDB returned $CMDBRowCount computers.  SCOM returned $ComputerCount Computers.  Discovery returned $CMDBMatchComputerCount matching computers from the CMDB and SCOM.  Runtime was $ScriptTime seconds")

You will need to change the SQL server name, DB name, and query, along with adding/changing the properties you want in the relevant sections.

You can review the discovery data in discovered inventory:

I also added rich logging to the script to understand what is happening:

Log Name:      Operations Manager
Source:        Health Service Script
Date:          12/4/2016 3:00:30 PM
Event ID:      8888
Level:         Information
Computer:      SCOMA1.opsmgr.net
Description:
DemoCMDB.Windows.Computer.Extended.Class.Discovery.Script.ps1 : Script has completed.  CMDB returned 8 computers.  SCOM returned 26 Computers.  Discovery returned 6 matching computers from the CMDB and SCOM.  Runtime was 5.7812508 seconds

I am attaching the sample MP file, along with the sample CSV registry file, at the following location:

https://gallery.technet.microsoft.com/Extend-Windows-Computer-13486493

Consider the scenario –  you want to monitor the event logs for a specific event, however, this event has a tendency to “storm” or log hundreds of events in a short time window.  Not a good condition for a monitoring system, as you can quickly overwhelm the system, nor do you want hundreds or thousands of alerts for a single condition.

The traditional approach to this would be to enable “Alert Suppression” which will increment a repeat counter on the alert.  This has a few negative effects:

1.  You still overwhelm the monitoring system, as you have to write this incremented counter to both the OpsDB and the DW.  Although this is not as expensive and creating multiple individual alerts, it still has significant impact.

2.  You will only get a notification on your FIRST alert.  All subsequent alerts will increment the counter, but you will never get another email/ticket on this again, as long as the original alert is still open.

Another approach – is to use a consolidator condition detection.  This is similar to the solution I provided here:  https://blogs.technet.microsoft.com/kevinholman/2014/12/18/creating-a-repeated-event-detection-rule/

The different, however, is instead of waiting for a specific “count” of events to fire in a specific time window, this example will do the following:

1. Wait for the event to exist in the event log.
2. Start a timer upon the first event, then wait for the timer to expire
3. Create an alert for the event(s), no matter if there was a single event or thousands of events in the timed window.

The XML is fairly simple for this.  We will have the following components:

1. Event datasource  (Microsoft.Windows.EventProvider)
2. Consolidation Condition Detection  (System.ConsolidatorCondition)
3. Alert Write Action   (System.Health.GenerateAlert)

Here is the datasource:   we simply look for event ID “123”

      <Rule ID="Demo.AlertOnConsolidatedEvent.Event123.Alert.Rule" Enabled="true" Target="Windows!Microsoft.Windows.Server.OperatingSystem" ConfirmDelivery="true" Remotable="true" Priority="Normal" DiscardLevel="100">
        <Category>Alert</Category>
        <DataSources>
          <DataSource ID="DS" TypeID="Windows!Microsoft.Windows.EventProvider">
            <ComputerName>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</ComputerName>
            <LogName>Application</LogName>
            <Expression>
              <SimpleExpression>
                <ValueExpression>
                  <XPathQuery Type="UnsignedInteger">EventDisplayNumber</XPathQuery>
                </ValueExpression>
                <Operator>Equal</Operator>
                <ValueExpression>
                  <Value Type="UnsignedInteger">123</Value>
                </ValueExpression>
              </SimpleExpression>
            </Expression>
          </DataSource>
        </DataSources>

Here is the condition detection.  Notice there is no counting condition, simply the timer window, where my example uses 30 seconds.

        <ConditionDetection ID="CD" TypeID="System!System.ConsolidatorCondition">
          <Consolidator>
            <ConsolidationProperties>
            </ConsolidationProperties>
            <TimeControl>
              <WithinTimeSchedule>
                <Interval>30</Interval>
                <!-- seconds -->
              </WithinTimeSchedule>
            </TimeControl>
            <CountingCondition>
              <CountMode>OnNewItemNOP_OnTimerOutputRestart</CountMode>
            </CountingCondition>
          </Consolidator>
        </ConditionDetection>

And finally – a simple write action to generate the alert:

        <WriteActions>
          <WriteAction ID="WA" TypeID="Health!System.Health.GenerateAlert">
            <Priority>1</Priority>
            <Severity>1</Severity>
            <AlertMessageId>$MPElement[Name="Demo.AlertOnConsolidatedEvent.Event123.Alert.Rule.AlertMessage"]$</AlertMessageId>
            <AlertParameters>
              <AlertParameter1>$Data/Count$</AlertParameter1>
              <AlertParameter2>$Data/TimeWindowStart$</AlertParameter2>
              <AlertParameter3>$Data/TimeWindowEnd$</AlertParameter3>
              <AlertParameter4>$Data/Context/DataItem/EventDescription$</AlertParameter4>
            </AlertParameters>
          </WriteAction>

When I fire off a LOT of Event ID 123 events:

eventcreate /T ERROR /ID 123 /L APPLICATION /SO TEST /D “This is a Test event 123”

I only get a single, consolidated Alert, after the 30 second time window expires:

I will attach the entire MP example here:

https://gallery.technet.microsoft.com/SCOM-Alerting-on-Events-930464cc

Silect is looking for user community feedback, to see if it is valuable to support the import of VSAE fragments into MP author, to extend the types of workflows that MP Author could support.

They are looking to see how valuable this would be, and how many MP authors would actually use and benefit from this type of extensibility?

You can comment on their blog post here to let them know your opinion: 

http://www.silect.com/support-vsae-mp-fragments-in-mp-author/

If you want to better understand MP fragments:

https://blogs.technet.microsoft.com/kevinholman/2016/06/04/authoring-management-packs-the-fast-and-easy-way-using-visual-studio/

Or watch the video of these fragments and Visual Studio in action: 

https://youtu.be/9CpUrT983Gc

The Windows Server Operating System MP’s (2003 – 2012R2) have been updated.

Download link:

https://www.microsoft.com/en-us/download/details.aspx?id=9296

This MP’s is a minor update streamlined to work with the same Base OS libraries from the separate download for Windows Server 2016:

https://www.microsoft.com/en-us/download/details.aspx?id=54303

From the guide:

Changes in Version 6.0.7323.0
•    Added Storport Miniport monitor for monitoring Event ID 153 in Windows Server 2003, 2008 and 2012 platforms.
•    Fixed bug: Logical Disk MB Free Space and Percentage Free Space monitor issues: Operator can set the threshold values for Error state even within Warning state default thresholds. At that, the Error state will supersede the Warning state according to the set values. Error threshold is independent of the Warning threshold.
•    Fixed localization issue with root report folder in the Report Library.
•    Windows Server Cluster Shared Volume Monitoring management pack is now supporting Nano Server and Windows Server 2016. Please note that Nano Server monitoring is supported by SCOM 2016 only.
•    Fixed bug with duplicating Nano Server Cluster Disk and Nano Server Cluster Shared Volumes health discoveries upon MP upgrade. See Troubleshooting and Known Issues section for details.
•    Fixed bug: Windows Server 2003 Computer discovery was causing repeated log events (EventID: 10000) due to improper discovery of non-2003 Windows Server computers.
•    Fixed bug: Windows Server 2008 Computer discovery was causing repeated log events (EventID: 10000) due to improper discovery of non-2008 Windows Server computers.
•    Fixed bug: Windows Server 2008 R2 Computer discovery was causing repeated log events (EventID: 10000) due to improper discovery of non-2008 R2 Windows Server computers.
•    Fixed bug: Windows Server 2012 Computer discovery was causing repeated log events (EventID: 10000) due to improper discovery of non-2012 Windows Server computers.
•    Fixed bug: Windows Server 2012 R2 Computer discovery was causing repeated log events (EventID: 10000) due to improper discovery of non-2012 R2 Windows Server computers.
•    Fixed bug: [Nano Server] Cluster Seed Name discovery was causing repeated log events (EventID: 10000) due to improper discovery of non-Nano objects.

They all import just fine:

Note that the cluster disks, library, and reports MP are 10.0.8.0 by design:

I recently had an interesting customer issue.

They wanted to collect some specific events for reporting.  This was specific to NTLM authentications.  The problem was – that these events could potentially FLOOD some servers, and they didn’t want to collect ALL the events, just a sample of unique events on a somewhat regular basis, so understand how often this happens.

SCOM is the perfect tool for this, because of the Consolidator Condition Detection Module.  Let me explain.

Writing a SCOM event collection rule is simple and easy.  But in this case – we need to “consolidate” these events, and only collect ONE event in a set time period.  For this – we will add a single condition detection to our rule, which is the System.ConsolidatorCondition

This is very similar to the rules I demonstrated here:

https://blogs.technet.microsoft.com/kevinholman/2014/12/18/creating-a-repeated-event-detection-rule/

https://blogs.technet.microsoft.com/kevinholman/2016/12/04/alerting-on-events-waiting-for-a-specific-amount-of-time-to-pass/

The rule will look just like most event rules, it has a Microsoft.Windows.EventProvider datasource, and two write actions to collect the event to the OpsDB and DW.  However, it will have a condition detection added. 

Here is the XML for the rule:

      <Rule ID="Demo.CollectConsolidatedEvent.Event999.Rule" Enabled="true" Target="Windows!Microsoft.Windows.Server.OperatingSystem" ConfirmDelivery="true" Remotable="true" Priority="Normal" DiscardLevel="100">
        <Category>Custom</Category>
        <DataSources>
          <DataSource ID="DS" TypeID="Windows!Microsoft.Windows.EventProvider">
            <ComputerName>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</ComputerName>
            <LogName>Application</LogName>
            <Expression>
                <And>
                    <Expression>
                      <SimpleExpression>
                        <ValueExpression>
                          <XPathQuery Type="UnsignedInteger">EventDisplayNumber</XPathQuery>
                        </ValueExpression>
                        <Operator>Equal</Operator>
                        <ValueExpression>
                          <Value Type="UnsignedInteger">999</Value>
                        </ValueExpression>
                      </SimpleExpression>
                    </Expression>
                    <Expression>
                      <SimpleExpression>
                        <ValueExpression>
                          <XPathQuery Type="String">PublisherName</XPathQuery>
                        </ValueExpression>
                        <Operator>Equal</Operator>
                        <ValueExpression>
                          <Value Type="String">TEST</Value>
                        </ValueExpression>
                      </SimpleExpression>
                    </Expression>
                </And>
            </Expression>
          </DataSource>
        </DataSources>
        <ConditionDetection ID="CD" TypeID="Demo.CollectConsolidatedEvent.Consolidate999ThenMapCD" />
        <WriteActions>
          <WriteAction ID="CollectEventOpsDB" TypeID="SC!Microsoft.SystemCenter.CollectEvent" />
          <WriteAction ID="CollectEventDWDB" TypeID="SCDW!Microsoft.SystemCenter.DataWarehouse.PublishEventData"/>
        </WriteActions>
      </Rule>

Notice the line for the condition detection:

        <ConditionDetection ID=”CD” TypeID=”Demo.CollectConsolidatedEvent.Consolidate999ThenMapCD” />

This is a custom composite condition detection I wrote – which does two things:

1.  It will consolidate all the events into a single Consolidated DataItem.

2.  Since the event collection write actions require Microsoft.Windows.EventData as an input, and the Consolidator outputs System.ConsolidatorData, we need to add something called a “Mapper” which will convert one data type to another.  In this case, I will be using the System.Event.GenericDataMapper  You don’t need to understand the nitty gritty…. but basically I will be mapping data from the first module so it can be output as standard event data for the collection write actions to consume.  Mappers are really cool – because they let us take data from ANYTHING and make it look like events, perf data, etc.  We can hard-code mapper values, or we can pass then dynamic data from the previous module.

Here is the custom composite condition detection I used:

      <ConditionDetectionModuleType ID="Demo.CollectConsolidatedEvent.Consolidate999ThenMapCD" Accessibility="Internal" Batching="false" Stateful="true" PassThrough="false">
        <Configuration>
        </Configuration>
        <ModuleImplementation Isolation="Any">
          <Composite>
            <MemberModules>
              <ConditionDetection ID="Consolidate" TypeID="System!System.ConsolidatorCondition">
                <Consolidator>
                  <ConsolidationProperties>
                    <!--  If you want to consolidate ONLY events with matching identical parameters and collect multiple events when params are different, uncomment this section for your specific params -->
                    <!--
                    <PropertyXPathQuery>Params/Param[1]</PropertyXPathQuery>
                    <PropertyXPathQuery>Params/Param[3]</PropertyXPathQuery>
                    <PropertyXPathQuery>Params/Param[5]</PropertyXPathQuery>
                    -->
                  </ConsolidationProperties>
                  <TimeControl>
                    <WithinTimeSchedule>
                      <Interval>30</Interval>
                      <!-- set the time windows to look for events in seconds -->
                    </WithinTimeSchedule>
                  </TimeControl>
                  <CountingCondition>
                    <CountMode>OnNewItemNOP_OnTimerOutputRestart</CountMode>
                  </CountingCondition>
                </Consolidator>
              </ConditionDetection>
              <ConditionDetection ID="EventMapper" TypeID="System!System.Event.GenericDataMapper">
                <EventOriginId>$Target/Id$</EventOriginId>
                <PublisherId>$MPElement$</PublisherId>
                <PublisherName>$Data/Context/DataItem/PublisherName$</PublisherName>
                <Channel>$Data/Context/DataItem/Channel$</Channel>
                <LoggingComputer>$Data/Context/DataItem/LoggingComputer$</LoggingComputer>
                <EventNumber>$Data/Context/DataItem/EventNumber$</EventNumber>
                <EventCategory>$Data/Context/DataItem/EventCategory$</EventCategory>
                <EventLevel>$Data/Context/DataItem/EventLevel$</EventLevel>
                <UserName />
                <Description>$Data/Context/DataItem/EventDescription$</Description>
                <Params />
              </ConditionDetection>
            </MemberModules>
            <Composition>
              <Node ID="EventMapper">
                <Node ID="Consolidate" />
              </Node>
            </Composition>
          </Composite>
        </ModuleImplementation>
        <OutputType>System!System.Event.Data</OutputType>
        <InputTypes>
          <InputType>Windows!Microsoft.Windows.EventData</InputType>
        </InputTypes>
      </ConditionDetectionModuleType>

If you haven’t ever looks at one of these, it is pretty complex at first.  I will do my best to break this down:

First – the rule has a datasource (Event Provider) that looks for Event 999 with source of TEST.  That’s pretty simple.

Next – the rule passes this event data to the custom condition detection.

The Condition Detection first loads the consolidator module – to consolidate matching event data in a specified time window.  In this case I used 30 seconds.  This means the consolidator will start a timer upon the first event, and wait until the 30 second window has passed to output the single consolidated dataitem.

Next – the Mapper module can be hard coded for output of each event parameter, or we can pass the individual stuff from the consolidated dataitem, which I have done here.  And example would be getting the event ID from the Consolidator – and passing it to the mapper:

<PublisherName>$Data/Context/DataItem/PublisherName$</PublisherName>
<Channel>$Data/Context/DataItem/Channel$</Channel>
<LoggingComputer>$Data/Context/DataItem/LoggingComputer$</LoggingComputer>
<EventNumber>$Data/Context/DataItem/EventNumber$</EventNumber>
<EventCategory>$Data/Context/DataItem/EventCategory$</EventCategory>
<EventLevel>$Data/Context/DataItem/EventLevel$</EventLevel>

The result of this – is that no matter how many events are spammed in the log, I will only collect a SINGLE event every 30 seconds, greatly reducing the number of events in the SCOM databases.  Realistically, we might use times closer to one event per hour maximum if this is a seriously flooding event.

Here is how the event looks as collected.  For the most part it appears just like normal eventdata, except it also includes information like how many times it occurred, and details on the time window:

You can download the management pack example here:

https://gallery.technet.microsoft.com/SCOM-management-pack-62744a89

I recently wrote a blog article on Extending the Windows Computer class from Registry keys on agents.  You can read about that here:  https://blogs.technet.microsoft.com/kevinholman/2016/12/04/extending-windows-computer-class-from-registry-keys-in-scom/

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 filesystem 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 = "ubuntu.opsmgr.net"

#=================================================================================
# 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:

https://gallery.technet.microsoft.com/Extend-UNIXLinux-Computer-57284056

This is a script example on how to get statechangeevents from monitor context using PowerShell.  This example uses a URL transaction monitor, but you can change this to any class/classinstance.

#Set arrays to empty
$Monitor = @()
$MonitorColl = @()
$States = @()

#Get Web Transaction URL Class
$URLClass = Get-SCOMClass -Name 'Microsoft.SystemCenter.WebApplication.Perspective'
#Get an array of matching specific instances of URL Class
$URLInstances = $URLClass | Get-SCOMClassInstance | where {$_.displayname -eq "Bing URL Transaction"}

#Loop through each URL instance
ForEach ($UrlTest in $URLInstances)
{
    #Set the monitor collection to empty and create the collection to contain monitors
    $MonitorColl = @()
    $MonitorColl = New-Object "System.Collections.Generic.List[Microsoft.EnterpriseManagement.Configuration.ManagementPackMonitor]"

    #Get specific monitors matching a displayname for this instance of URLtest ONLY
    $Monitor = Get-SCOMMonitor -Instance $UrlTest -Recurse | where {$_.DisplayName -eq "Content Match"}

    #Add this monitor to a collection
    $MonitorColl.Add($Monitor)

    #Get the state associated with this specific monitor
    $State=$UrlTest.getmonitoringstates($MonitorColl)

    #Add each state found in the loop to an array to be used later
    $States += $State
}

#get any statechangeevents for each item in the array
$States[0].getmonitoringstatechangeevents()
$States[1].getmonitoringstatechangeevents()

I will try to use this post as a running record to help you find all the MP’s that we have released for Windows Server 2016 OS and the unique server roles for which we create MP’s for.

As with all MP’s, you should give great scrutiny, and only import MP’s that are directly relevant to your monitoring requirements.

Last updated 12-22-2016

This is pretty exciting.

Microsoft just shipped a totally new AD MP.  This one has no dependencies on the previous ADMP, that has been mostly based on the same core design for the past 15 years!

https://www.microsoft.com/en-us/download/details.aspx?id=54525

The new ADMP supports monitoring Active Directory when yours DC’s are Windows Server 2012, 2012R2, or 2016.

There is a huge list of changes, but the biggest impactful ones in my opinion are:

• No more OOMADS!
• Removed Reliance on OOMADS.dll for Domain Controller monitoring removed oomads dependency from all MPs.  This was always a pain when managing DC’s in the past, now it is no longer required for the ADMP scripts to work.
• Replication Monitoring rewrite.
• This was previously a nightmare solution of 14 rules and monitors which all shared the same script datasource, for EACH OS version you had DC’s on.  Tuning replication monitoring in the past was very challenging for customers.  Now – it has been streamlined via scenario, as Replication Monitoring was replaced with the following monitors:
• AD Replication Queue Monitor
• AD Show Replication Check
• Replication Partner Count Monitor
• Replication Consistency Monitor
• Removed dependency on down-level DC discovery MPs.
• You no longer have to import the old Windows 2000, 2003, and 2008 AD Discovery MP’s if you aren’t using those versions, like the old MP’s required.
• A total required of the old “AD Client Monitoring” which is renamed to “Domain Member Monitoring”
• The Domain Member Monitoring Management Pack deploys a set of rules and monitors to a computer that represents an Active Directory member server or client. These rules and monitors provide monitoring data, such as connectivity, latency and availability, from the perspective of the member.

See the MP guide for the full list of fixes and updates.

At the time of this writing – the MP version is 10.0.1.0.

This MP does NOT UPGRADE the previous MP’s.  This is designed as a replacement.  However, you can run both MP’s side by side if you want to cut over monitoring slowly.  You should delete all the previous older generation ADMP’s from your management group and use this MP, provided your DC’s are all WS2012 or later.

The MP’s import just fine:

The guide is pretty thorough on the monitoring scenarios – I recommend you review it before using the MP.

• Monitoring Scenarios
• Multi-Forest Monitoring
• Replication
• Essential Services
• SYSVOL Availability
• Trust Monitoring
• Directory Service Availability
• AD Database Monitoring
• Time Skew Monitoring
• AD Web Service Monitoring
• Domain Controller Performance
• Domain Member Perspective (the old AD Client Monitoring)

The SQL MP’s have been updated.

New Features and Fixes

• No extra permissions on remote WMI are now required for Local System account when Always On hosts have names that are no longer than 15 symbols
• Fixed: Always On discovery and monitoring scripts cannot read cached values in Windows registry
• Fixed: Wrong MP version number in some Always On scripts
• Fixed: CPUUsage and DBDiskLatency scripts fail with the reason: “Index operation failed”
• Fixed: Always On objects get undiscovered when any Always On discovery crashes
• Added retry policy in some Always On workflows to make PS-scripts work more stable
• Updated the visualization library
• Fixed: AS workflows sometimes crash
• Changed behavior of Always On scripts for cases when WSFC service is stopped
• Fixed: Tiles content is replaced with question signs after a long period of inactivity

An update was recently released.  This can be considered the “UR1” update for the SCOM 2016 Linux MP’s.  Note – these are for SCOM 2016 ONLY.  Do not attempt to import SCOM 2016 Linux MP’s into SCOM 2012. 

https://www.microsoft.com/en-us/download/details.aspx?id=29696

Make sure you get the correct version:

Download, extract, and import the MP’s that are relevant to what you monitor:

This will take a considerable amount of time to import, and consume a lot of CPU on the management servers and SQL server until complete.

Once it has completed, you will need to restart the Healthservice (Microsoft Monitoring Agent) on each management server, in order to get them to update their agent files at \Program Files\Microsoft System Center 2016\Operations Manager\Server\AgentManagement\UnixAgents

You should see the new files dropped with new timestamps:

Now you can deploy the agent updates:

Next – you decide if you want to input credentials for the SSH connection and upgrade, or if you have existing RunAs accounts that are set up to do the job (Agent Maintenance/SSH Account)

FAILED!!!

I am using an account as the agent maintenance account, and this is using SUDO elevation.  The error I got back was that ASKPASS and TTY unknown or unspecified.

This wasn’t correct, however, there command to run in the SUDOERS file is very specific – and this is probably my problem.

With the assistance of Tim Helton we looked for the error in /VAR/log/auth.log, where we found:

Jan  9 10:54:11 ubuntu sshd[35292]: pam_unix(sshd:session): session opened for user scxmaint by (uid=0)
Jan  9 10:54:11 ubuntu sudo: pam_unix(sudo:auth): conversation failed
Jan  9 10:54:11 ubuntu sudo: pam_unix(sudo:auth): auth could not identify password for [scxmaint]
Jan  9 10:54:11 ubuntu sudo: pam_unix(sudo:auth): conversation failed
Jan  9 10:54:11 ubuntu sudo: pam_unix(sudo:auth): auth could not identify password for [scxmaint]
Jan  9 10:54:11 ubuntu sudo: pam_unix(sudo:auth): conversation failed
Jan  9 10:54:11 ubuntu sudo: pam_unix(sudo:auth): auth could not identify password for [scxmaint]
Jan  9 10:54:11 ubuntu sudo: scxmaint : 3 incorrect password attempts ; TTY=unknown ; PWD=/home/scxmaint ; USER=root ; COMMAND=/bin/sh -c sh /tmp/scx-scxmaint/scx-1.6.2-337.universald.1.x64.sh –upgrade –force; EC=$?; cd /tmp; rm -rf /tmp/scx-scxmaint; exit $EC

When I compared this to my sample SUDOERS file from:  https://blogs.technet.microsoft.com/kevinholman/2016/11/11/monitoring-unixlinux-with-opsmgr-2016/  I can see the issue.

Example SUDOERS file:

#Linux

scxmaint ALL=(root) NOPASSWD: /bin/sh -c sh /tmp/scx-scxmaint/scx-1.[5-9].[0-9]-[0-9][0-9][0-9].universal[[\:alpha\:]].[[\:digit\:]].x[6-8][4-6].sh –install; EC=$?; cd /tmp; rm -rf /tmp/scx-scxmaint; exit $EC

scxmaint ALL=(root) NOPASSWD: /bin/sh -c sh /tmp/scx-scxmaint/scx-1.[5-9].[0-9]-[0-9][0-9][0-9].universal[[\:alpha\:]].[[\:digit\:]].x[6-8][4-6].sh –upgrade

The upgrade command we are trying to run (from the auth.log) doesn’t match the command in sudoers.  So I update the sudoers file line for upgrade to this:

scxmaint ALL=(root) NOPASSWD: /bin/sh -c sh /tmp/scx-scxmaint/scx-1.[5-9].[0-9]-[0-9][0-9][0-9].universal[[\:alpha\:]].[[\:digit\:]].x[6-8][4-6].sh –upgrade –force; EC=$?; cd /tmp; rm -rf /tmp/scx-scxmaint; exit $EC

Now:

So if you are getting a rights error from a sudo elevated account, always look in /var/log/messages or /var/log/auth and see if you can find a discrepancy in what you are attempting to run, versus what you have rights to run.

I will update the sample SUDOERS file to contain this change at https://blogs.technet.microsoft.com/kevinholman/2016/11/11/monitoring-unixlinux-with-opsmgr-2016/

When SCOM 2016 UR1 shipped – the only DB platforms supported were SQL 2014 SP2, and SQL 2016.

However, for SCOM 2012 R2 users, most were running SQL 2012.  This meant, in order to upgrade to SCOM 2016…..  you had to FIRST upgrade your SQL servers to a SQL platform that supports BOTH versions.  Before now, that meant your ONLY choice was SQL 2014 SP2.

We are now announcing support for SCOM 2016 on SQL 2012 SP3.

This will make an in-place upgrade of SCOM 2016 much simpler.  Most SCOM 2012 R2 environments will be able to simply ensure all SQL servers (OpsDB, DW, and Reporting/SRS) are running SQL 2012 SP3, and be able to have a successful and supported upgrade path to SCOM 2016.

Then if the customer so chooses, they can upgrade or migrate these SQL servers to a later supported version of SQL on their own schedule.

As of this writing – the documentation is being updated, but here are the current supported configuration links regarding SQL and SCOM support:

SCOM 2012 R2 supported SQL versions:

https://technet.microsoft.com/en-us/library/dn281933(v=sc.12).aspx    (this table doesn’t fit the browser, you need to slide it left and right to see all versions)

SCOM 2016 supported SQL versions:

https://technet.microsoft.com/en-us/system-center-docs/om/plan/planning-sqlserver-design#sql-server-requirements

When you first install reporting, you have to supply a management server.  This is used for SDK based connections that SCOM reporting requires.  If you ever retire this management server, reporting will break so this is an additional step to ensure you check whenever you retire a MS.

There are three places you need to update to a new management server:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center Operations Manager\12\Reporting\DefaultSDKServiceMachine

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Reporting\DefaultSDKServiceMachine

and TWO places in the file:

rsreportserver.config on your SSRS server path similar to:  \Program Files\Microsoft SQL Server\MSRS11.MSSQLSERVER\Reporting Services\ReportServer

(You could always just uninstall SCOM reporting and reinstall it somewhere else…. but that would be a bit drastic, don’t you think?)

KB Article for OpsMgr:  https://support.microsoft.com/en-us/help/3209587/system-center-2012-r2-om-ur12

Download catalog site:  http://www.catalog.update.microsoft.com/Search.aspx?q=3209587

NOTE:  I get this question every time we release an update rollup:   ALL SCOM Update Rollups are CUMULATIVE.  This means you do not need to apply them in order, you can always just apply the latest update.  If you have deployed SCOM 2012R2 and never applied an update rollup – you can go straight to the latest one available.  If you applied an older one (such as UR3) you can always go straight to the latest one!

Key Fixes:

• SCOM 2016 Upgrade failure:  When you try to upgrade System Center 2012 R2 Operations Manager Reporting Server to System Center 2016 Operations Manager reporting server, the upgrade fails for the following configuration:

  • Server A is configured as System Center 2012 R2 Operations Manager including Management Server.
  • Server B is configured as System Center 2012 R2 Operations Manager, including Operations Manager Database (OpsMgrDB), Operations Manager Data Warehouse (OpsMgrDW) and Operations Manager Reporting Server.
  • ( X ) Management Server Upgraded Check – The management server to which this component reports has not been upgraded.
• Recovery tasks on “Computer Not Reachable” messages in the System Center Operations Manager Monitor generate failed logons for System Center Operations Manager Agents that are not part of the same domain as the Management Groups.
• Resource pools:  When a Management Server is removed from the All Management Servers Resource Pool, the monitoring host process do not update the Type Space Cache.
• SHA2 support for certificates:  SHA1 is deprecated for the System Center 2012 R2 Operations Manager Agent and SHA2 is now supported.
• Override fixes:  Because of incorrect computations of configuration and overrides, some managed entities go into an unmonitored state. This behavior is accompanied by event 1215 errors that are logged in the Operations Manager log.
• IntelliTrace Profiling workflows fail on certain Windows operating system versions. The workflow cannot resolve Shell32 interface issues correctly.
• Notifications:  There is a character limitation of 50 characters on the custom fields in the notification subscription criteria. This update increases the size of the limitation to 255 characters.
• OMS:  You cannot add Windows Client computers for Operational Insights (OMS) monitoring. This update fixes the OMS Managed Computers wizard in the System Center Operations Manager Administration pane to let you search or add Windows Client computers.

• When you use the Unix Process Monitoring Template wizard to add a new template to the monitor processes on UNIX servers, the monitored data is not inserted into the database. This issue occurs until the Monitoring Host is restarted. Additionally, the following is logged in the Operations Manager log file:

  Log Name:      Operations Manager
  Source:        Health Service Modules
  Event ID:      10801
  Level:         Error
  Description:    Discovery data couldn’t be inserted to the database. This could have happened because of one of the following reasons:
        – Discovery data is stale. The discovery data is generated by an MP recently deleted.
        – Database connectivity problems or database running out of space.
        – Discovery data received is not valid.

  Additionally, you may receive the following exception, which causes this issue to occur:

  Exception:

  Exception type:   Microsoft.EnterpriseManagement.Common.DataItemDoesNotExistException
  Message:          ManagedTypeId = ccf81b2f-4b92-bbaf-f53e-d42cd9591c1c
  InnerException:   <none>
  StackTrace (generated):   SP IP Function   000000000EE4EF10 00007FF8789773D5 Microsoft_EnterpriseManagement_DataAccessLayer!Microsoft.EnterpriseManagement.DataAccessLayer.TypeSpaceData.IsDerivedFrom(System.Guid, System.Guid)+0x385

   

New Linux operating systems supported

• RHEL 7 on Power8 is now supported in System Center2012 R2 Operations Manager
  

   

Issues that are fixed in the UNIX and Linux management packs

• SHA2 support:  SHA1 is deprecated and SHA2 is now supported on the management server that’s used to sign the UNIX/Linux Operations Manager i (OMi) certificate.
• OMI and FIPS support:  OMi start attempts fail on all FIPS-enabled UNIX/Linux systems. This fix updates the agents to support FIPS-enabled systems.
• HPUX fix:  The Average Physical disk sec/transfer performance counters are not displayed for Hewlett Packard systems.
• Solaris 10 fix:  OMi displays incorrect memory information for Solaris 10 systems.
• SLES fix:  The Network Adapter Performance counter is not displayed for SLES 12 x64 platforms in the console.
• HPUX fix:  You can’t discover file systems on HPUX 11.31 IA-64 computers that have more than 128 disks. Previously, only 128 VGs were supported. This update extends support to 256 VGs.
• JBOSS fix:  Deep monitoring can’t be started successfully for some Jboss applications because the discovery of the Jboss application server sets the DiskPath for the Jboss server incorrect. Deep monitoring is not started in JBoss stand-alone mode when a nondefault configuration is used. This update provides additional support for JBoss stand-alone mode.

Lets get started.

From reading the KB article – the order of operations is:

1. Install the update rollup package on the following server infrastructure:
   • Management servers
   • Audit Collection servers 
   • Gateway servers
   • Web console server role computers
   • Operations console role computers
   • Reporting
2. Apply SQL scripts.
3. Manually import the management packs.
4. Update Agents
5. Unix/Linux management packs and agent updates.

1.  Management Servers

It doesn’t matter which management server I start with.  There is no need to begin with whomever holds the “RMSe” role.  I simply make sure I only patch one management server at a time to allow for agent failover without overloading any single management server.

I can apply this update manually via the MSP files, or I can use Windows Update.  I have 2 management servers, so I will demonstrate both.  I will do the first management server manually.  This management server holds 3 roles, and each must be patched:  Management Server, Web Console, and Console.

The first thing I do when I download the updates from the catalog, is copy the cab files for my language to a single location:

Then extract the contents:

Once I have the MSP files, I am ready to start applying the update to each server by role.

***Note:  You MUST log on to each server role as a Local Administrator, SCOM Admin, AND your account must also have System Administrator role to the SQL database instances that host your OpsMgr databases.

My first server is a Management Server Role, and the Web Console Role, and has the OpsMgr Console installed, so I copy those update files locally, and execute them per the KB, from an elevated command prompt:

This launches a quick UI which applies the update.  It will bounce the SCOM services as well.  The update usually does not provide any feedback that it had success or failure. 

You can check the application log for the MsiInstaller events to show completion:

Log Name:      Application
Source:        MsiInstaller
Date:          8/31/2016 9:01:13 AM
Event ID:      1036
Description:
Windows Installer installed an update. Product Name: System Center Operations Manager 2012 Server. Product Version: 7.1.10226.0. Product Language: 1033. Manufacturer: Microsoft Corporation. Update Name: System Center 2012 R2 Operations Manager UR11 Update Patch. Installation success or error status: 0.

You can also spot check a couple DLL files for the file version attribute. 

Next up – run the Web Console update:

This runs much faster.   A quick file spot check:

Lastly – install the console update (make sure your console is closed):

A quick file spot check:

Additional Management Servers:

I now move on to my additional management servers, applying the server update, then the console update and web console update where applicable.

On this next management server, I will use the example of Windows Update as opposed to manually installing the MSP files.  I check online, and make sure that I have configured Windows Update to give me updates for additional products: 

The applicable updates show up under optional – so I tick the boxes and apply these updates.

After a reboot – go back and verify the update was a success by spot checking some file versions like we did above.

Updating ACS (Audit Collection Services)

You would only need to update ACS if you had installed this optional role.

On any Audit Collection Collector servers, you should run the update included:

A spot check of the files:

Updating Gateways:

I can use Windows Update or manual installation.

The update launches a UI and quickly finishes.

I was prompted for a reboot.

Then I will spot check the DLL’s:

I can also spot-check the \AgentManagement folder, and make sure my agent update files are dropped here correctly:

***NOTE:  You can delete any older UR update files from the \AgentManagement directories.  The UR’s do not clean these up and they provide no purpose for being present any longer.

I can also apply the GW update via Windows Update:

Reporting Server Role Update

I kick off the MSP from en elevated command prompt:

This runs VERY fast and does not provide any feedback on success or failure.

2. Apply the SQL Scripts

In the path on your management servers, where you installed/extracted the update, there are two SQL script files: 

%SystemDrive%\Program Files\Microsoft System Center 2012 R2\Operations Manager\Server\SQL Script for Update Rollups

(note – your path may vary slightly depending on if you have an upgraded environment or clean install)

First – let’s run the script to update the OperationsManagerDW (Data Warehouse) database.  Open a SQL management studio query window, connect it to your Operations Manager DataWarehouse database, and then open the script file (UR_Datawarehouse.sql).  Make sure it is pointing to your OperationsManagerDW database, then execute the script.

You should run this script with each UR, even if you ran this on a previous UR.  The script body can change so as a best practice always re-run this.

If you see a warning about line endings, choose Yes to continue.

Click the “Execute” button in SQL mgmt. studio.  The execution could take a considerable amount of time and you might see a spike in processor utilization on your SQL database server during this operation.

You will see the following (or similar) output:   “Command(s) completes successfully”

Next – let’s run the script to update the OperationsManager (Operations) database.  Open a SQL management studio query window, connect it to your Operations Manager database, and then open the script file (update_rollup_mom_db.sql).  Make sure it is pointing to your OperationsManager database, then execute the script.

You should run this script with each UR, even if you ran this on a previous UR.  The script body can change so as a best practice always re-run this.

Click the “Execute” button in SQL mgmt. studio.  The execution could take a considerable amount of time and you might see a spike in processor utilization on your SQL database server during this operation.  

I have had customers state this takes from a few minutes to as long as an hour. In MOST cases – you will need to shut down the SDK, Config, and Monitoring Agent (healthservice) on ALL your management servers in order for this to be able to run with success.

You will see the following (or similar) output: 

or

IF YOU GET AN ERROR – STOP!  Do not continue.  Try re-running the script several times until it completes without errors.  In a production environment with lots of activity, you will almost certainly have to shut down the services (sdk, config, and healthservice) on your management servers, to break their connection to the databases, to get a successful run.

Technical tidbit:   Even if you previously ran this script in any previous UR deployment, you should run this again in this update, as the script body can change with updated UR’s.

3. Manually import the management packs

There are 58 management packs in this update!   Most of these we don’t need – so read carefully.

The path for these is on your management server, after you have installed the “Server” update:

\Program Files\Microsoft System Center 2012 R2\Operations Manager\Server\Management Packs for Update Rollups

However, the majority of them are Advisor/OMS, and language specific.  Only import the ones you need, and that are correct for your language.  I will remove all the MP’s for other languages (keeping only ENU), and I am left with the following:

What NOT to import:

The Advisor MP’s are only needed if you are using Microsoft Operations Management Suite cloud service (OMS), (Previously known as Advisor, and Operations Insights).

The APM MP’s are only needed if you are using the APM feature in SCOM.

The Alert Attachment and TFS MP bundle is only used for specific scenarios, such as DevOps scenarios where you have integrated APM with TFS, etc.  If you are not currently using these MP’s, there is no need to import or update them.  I’d skip this MP import unless you already have these MP’s present in your environment.

However, the Image and Visualization libraries deal with Dashboard updates, and these always need to be updated.

I import all of these shown without issue.

4.  Update Agents

Agents should be placed into pending actions by this update for any agent that was not manually installed (remotely manageable = yes):  

One the Management servers where I used Windows Update to patch them, their agents did not show up in this list.  Only agents where I manually patched their management server showed up in this list.  FYI.   The experience is NOT the same when using Windows Update vs manual.  If yours don’t show up – you can try running the update for that management server again – manually.

If your agents are not placed into pending management – this is generally caused by not running the update from an elevated command prompt, or having manually installed agents which will not be placed into pending.

In this case – my agents that were reporting to a management server that was updated using Windows Update – did NOT place agents into pending.  Only the agents reporting to the management server for which I manually executed the patch worked.

I manually re-ran the server MSP file manually on these management servers, from an elevated command prompt, and they all showed up.

You can approve these – which will result in a success message once complete:

Soon you should start to see PatchList getting filled in from the Agents By Version view under Operations Manager monitoring folder in the console:

5.  Update Unix/Linux MPs and Agents

The current Linux MP’s can be downloaded from:

https://www.microsoft.com/en-us/download/details.aspx?id=29696

7.5.1068.0 is the SCOM 2012 R2 UR12 release version.  

****Note – take GREAT care when downloading – that you select the correct download for SCOM 2012 R2.  You must scroll down in the list and select the MSI for 2012 R2:

Download the MSI and run it.  It will extract the MP’s to C:\Program Files (x86)\System Center Management Packs\System Center 2012 R2 Management Packs for Unix and Linux\

Update any MP’s you are already using.   These are mine for RHEL, SUSE, and the Universal Linux libraries. 

You will likely observe VERY high CPU utilization of your management servers and database server during and immediately following these MP imports.  Give it plenty of time to complete the process of the import and MPB deployments.

Next – you need to restart the “Microsoft Monitoring Agent” service on any management servers which manage Linux systems.  I don’t know why – but my MP’s never drop/update the UNIX/Linux agent files in the \Program Files\Microsoft System Center 2012 R2\Operations Manager\Server\AgentManagement\UnixAgents\DownloadedKits folder until this service is restarted.

Next up – you would upgrade your agents on the Unix/Linux monitored agents.  You can now do this straight from the console:

You can input credentials or use existing RunAs accounts if those have enough rights to perform this action.

Finally:

6.  Update the remaining deployed consoles

This is an important step.  I have consoles deployed around my infrastructure – on my Orchestrator server, SCVMM server, on my personal workstation, on all the other SCOM admins on my team, on a Terminal Server we use as a tools machine, etc.  These should all get the matching update version.

You can use Help > About to being up a dialog box to check your console version:

Review:

Now at this point, we would check the OpsMgr event logs on our management servers, check for any new or strange alerts coming in, and ensure that there are no issues after the update.

Known issues:

See the existing list of known issues documented in the KB article.

1.  Many people are reporting that the SQL script is failing to complete when executed.  You should attempt to run this multiple times until it completes without error.  You might need to stop the Exchange correlation engine, stop all the SCOM services on the management servers, and/or bounce the SQL server services in order to get a successful completion in a busy management group.  The errors reported appear as below:

——————————————————
(1 row(s) affected)
(1 row(s) affected)
Msg 1205, Level 13, State 56, Line 1
Transaction (Process ID 152) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
Msg 3727, Level 16, State 0, Line 1
Could not drop constraint. See previous errors.
——————————————————–

There are certain management packs that will use product connectors to insert discovery data into SCOM, or to manage alerts.  Sometimes, you might find that the vendor did not provide a way to remove these product connectors, when you decide to stop using the MP or solution which created them.

Below is a PowerShell script that will allow you to remove them.  It supports inputting the product connector by name, or by a wildcard match using “*”.  The script will output all the matching connectors and allow you to choose to continue if you want them deleted.

***NEVER remove any product connector unless you are absolutely SURE of its origin and that it is one you want to delete.  It is a good idea to back up your databases before deleting connectors.

#===================================================
#
#  Delete a SCOM product connector in SCOM 2012 R2 and SCOM 2016 
#
#  v1.0
#
#===================================================

#===================================================
# Constants section - make changes here
$connectorName = "foo.connector*"  #This can be a full name or a partial name match with a wildcard (*) - so take great care here
$servername="localhost"
#===================================================

$mg = Get-SCOMManagementGroup -ComputerName $servername
$admin = $mg.GetConnectorFrameworkAdministration()
$connectors = $admin.GetMonitoringConnectors()
$subs = $admin.GetConnectorSubscriptions()

$ToBeDeletedNames = @()
$ToBeDeletedList = $admin.GetMonitoringConnectors() | where {$_.Name -like "$connectorname"}
FOREACH ($ToBeDeletedConn in $ToBeDeletedList)
{
  [array]$ToBeDeletedNames += "`n" + $ToBeDeletedConn.Displayname
}
Write-Host "About to delete the following connectors: " $ToBeDeletedNames
Write-Host "Press Y to continue, or any other key to stop"
$response = Read-Host
if ( $response -ne "Y" )
{
Write-Host "Cancelling"
exit
}


########################################################################################## 
# Delete a connector’s Subscription 
########################################################################################## 
function Delete-Subscription([String] $name)
{
  foreach($testconnector in $connectors)
  {
    if($testconnector.Name -match $name)
    {
      $connector = Get-SCOMConnector -id $testconnector.id
      write-host "Found match on connector:" $connector.Displayname

      foreach($sub in $subs)
      {
        if($sub.MonitoringConnectorId -eq $connector.id)
        {
          write-host "Deleting subscription:" $sub.DisplayName "with ID" $sub.MonitoringConnectorId
          $admin.DeleteConnectorSubscription($admin.GetConnectorSubscription($sub.Id))
        }
      }
    }
  }
}

########################################################################################## 
# Removes a connector with the specified name. 
########################################################################################## 
function Remove-Connector([String] $name)
{
  $testConnector = $null
  foreach($connector in $connectors)
  {
    IF ($connector.Name -like $name)
    {
      $testConnector = Get-SCOMConnector -id $connector.id
      write-host "Found match on connector:" $connector.Displayname
      IF ($testConnector -ne $null)
      {
        IF ($testConnector.Initialized)
        {
          Write-Host "Found connector is initialized, disconnecting all alerts subscribe to the connector"
          FOREACH ($alert in $testConnector.GetMonitoringAlerts())
          {
            $alert.ConnectorId = $null;
            $alert.Update("Delete Connector");
          }
          Write-Host "Setting connector to UnInitialized"
          $testConnector.Uninitialize()
        }
        Write-Host "Deleting connector:" $testConnector.DisplayName "with ID" $testConnector.Id
        $connectorIdForTest = $admin.Cleanup($testConnector)
      }
    }
  }
}

write-host "Starting Delete-Subscription function"
Delete-Subscription $connectorName
write-host "Starting Remove-Connector function"
Remove-Connector $connectorName

ACS (Audit Collection Services) in SCOM uses a WMI filter to reject certain events from being collected and stored in the Audit database.

This filter supports about 4800 characters, so the filters can get very large and very advanced.  It is important to test these before implementing to ensure you are getting a valid filter. 

ACS uses WQL queries.  https://msdn.microsoft.com/en-us/library/aa394606(v=vs.85).aspx

I recently had a customer trying to exclude a specific EventId from being collected, but ONLY when a specific parameter was present.

In the ACS event queue, the event parameters are mapped to specific “String” ID’s, which don’t match up to the parameter header or number….. so we must match on the specific StringID value.  The easies way to get this is to collect the event, and then search for it in the ACD DB.  In this case, my customer wanted to exclude event ID 4648, but only when String06 = “C:\Windows\System32\svchost.exe”

Seems easy enough?

Here is the first ACS filter we used:   SELECT * FROM AdtsEvent WHERE NOT (EventId=4648 AND String06=’C:\Windows\System32\svchost.exe’)

However, it didn’t work.  We still collected the 4648 event, even with this match in String06. 

One thing to always do before implementing a change in your ACS filter – is to TEST the syntax using WBEMTEST:

Open WBEMTEST on the ACS Collector. 

Connect to root\default

Select “Notification Query” button.

Paste in your exact query you want to use.

Hit “Apply”

I reached out to Jimmy Harper on this, as he is an ACS guru.

My rookie mistake.  I forgot that the “Backslash” is not allowed in a WMI query.  Backslash is a special character used to escape other special characters.  See:  https://msdn.microsoft.com/en-us/library/aa394054(v=vs.85).aspx

So in this case – if we want to use a backslash character, we need to escape it with another backslash.  Here is my new query:

SELECT * FROM AdtsEvent WHERE NOT (EventId=4648 AND String06=’C:\\Windows\\System32\\svchost.exe’)

I can test this in wbemtest and it works just fine.

KB Article for OpsMgr:  https://support.microsoft.com/en-us/help/3209591/update-rollup-2-for-system-center-2016-operations-manager

Download catalog site:  http://www.catalog.update.microsoft.com/Search.aspx?q=3209591

Recommended hotfix page:  https://blogs.technet.microsoft.com/kevinholman/2009/01/27/which-hotfixes-should-i-apply/ 

NOTE:  I get this question every time we release an update rollup:   ALL SCOM Update Rollups are CUMULATIVE.  This means you do not need to apply them in order, you can always just apply the latest update.  If you have deployed SCOM 2016 and never applied an update rollup – you can go straight to the latest one available. 

Key fixes:

• When you use the Unix Process Monitoring Template wizard (adding a new template) to monitor processes on UNIX servers, the monitored data is not inserted into the database because of the following failure:
  

  Source: Health Service Modules
  Event ID: 10801
  Description: Discovery data couldn’t be inserted to the database. This could have happened because of one of the following reasons:
  – Discovery data is stale. The discovery data is generated by an MP recently deleted.
  – Database connectivity problems or database running out of space.
  – Discovery data received is not valid.

  The following is the underlying exception that causes this issue:

  Exception type: Microsoft.EnterpriseManagement.Common.DataItemDoesNotExistException Message: ManagedTypeId = ccf81b2f-4b92-bbaf-f53e-d42cd9591c1c InnerException: StackTrace (generated): SP IP Function 000000000EE4EF10 00007FF8789773D5 Microsoft_EnterpriseManagement_DataAccessLayer!Microsoft.EnterpriseManagement.DataAccessLayer.TypeSpaceData.IsDerivedFrom(System.Guid, System.Guid)+0x385

• When a management server is removed from the All Management Servers Resource Pool, the monitoring host process does not update the TypeSpaceCache.
• When alerts are closed from the Alerts view after you run a Search, the closed Alerts still appear in the View when the Search is cleared.
• When you press Ctrl+C to copy an alert in Operations Manager Alert view and then press Ctrl+V to paste it to Notepad, the Created time is in UTC time, not local time.
• Groups disappear from Group view after they are added to a Distributed Application.
• IM notifications from Operating Manager to Skype fail when an incorrect exception causes NullReferenceException in the SipNotificationTransport.Send method.
• When the maintenance mode option for the dependency monitor is set to “Ignore,” and the group (consisting of the server to which this dependency monitor is targeted) is put in Maintenance mode, the state of the monitor changes to critical and does not ignore maintenance mode.
• Because of a rare scenario of incorrect computation of configuration and overrides, some managed entities may go into an unmonitored state. This behavior is accompanied by 1215 events that are written to the Operations Manager log.
• Recovery tasks on “Computer Not Reachable” Operations Manager Monitor generate failed logons on SCOM Agents that are not part of the same domain as the management groups.
• The ManagementGroupCollectionAlertsCountRule workflow fails and generates a “Power Shell Script failed to run” alert.
• Get-SCOMGroup cmdlet fails when thousands of groups are created in Operations Manager.
• Organizational unit properties for computers that are running Windows are not discovered or populated. This discovery is part of the System Center Internal Library MP. After this update, organizational unit properties will be discovered for all computers that are running Windows.
• When the Operations Manager Health Service agent starts, and the agent is configured for AD integration, if the agent cannot contact Active Directory at all, it immediately goes dormant and stops trying to connect and obtain the policy from Active Directory.

Issues that are fixed in the UNIX and Linux management packs

• SHA1 is deprecated, and SHA256 certificates are now supported on the management server that’s used to sign the Unix/Linux OMI certificate.
• OMI does not work on Linux servers configured for FIPS compliance.
• Avg. Physical disk sec/transfer performance counters are not displayed for Hewlett Packard computers.
• OMI displays incorrect Memory information on Solaris 10 computers.
• Network adapter performance is not displayed for SLES 12 x64 platform in the Operations Manager Console.
• Cannot discover file systems on HPUX 11.31 IA-64 computers with more than 128 disks. Previously it supported only 128 VGs. Now support is extended to 256 VGs.
• Deep monitoring cannot be started successfully on some JBoss applications because the discovery of the JBoss application server sets the Disk Path for the JBoss server incorrectly. Deep monitoring was not being started in JBoss stand-alone mode when a nondefault configuration was used.

Lets get started.

From reading the KB article – the order of operations is:

1. Install the update rollup package on the following server infrastructure:
   • Management server or servers
   • Agent
   • Nano Agent
   • Web console server role computers
   • Gateway
   • Operations console role computers
   • Reporting
2. Apply SQL scripts.
3. Manually import the management packs.
4. Update manually installed Nano Agents

I disagree with the order in the KB article.  Unless there is a documented reason to update agents before updating the rest of the infrastructure, this is a confusing step.  Most enterprise customers will update their agents on a slower rollout, and you should NOT wait to patch the Web Consoles, Gateways, Consoles, and Reporting until after your agents are updated. 

The KB article is also missing any mention of the ACS (Audit Collection Services) update which is included in this package.  So if you are using ACS – don’t miss that step.

So my recommended order will be:

1. Install the update rollup package on the following server infrastructure:
   • Management server or servers
   • Web console server role computers
   • Gateway
   • Operations console role computers
   • Reporting
   • ACS update
2. Apply SQL scripts.
3. Manually import the management packs.
4. Update Agents

Additionally, we will add the steps to update any Linux management packs and agents, if they are present.

1.  Management Servers

Since there is no RMS anymore, it doesn’t matter which management server I start with.  There is no need to begin with whomever holds the “RMSe” role.  I simply make sure I only patch one management server at a time to allow for agent failover without overloading any single management server.

I can apply this update manually via the MSP files, or I can use Windows Update.  I have 2 management servers, so I will demonstrate both.  I will do the first management server manually.  This management server holds 3 roles, and each must be patched:  Management Server, Web Console, and Console.

The first thing I do when I download the updates from the catalog, is copy the cab files for my language to a single location, and then extract the contents:

Once I have the MSP files, I am ready to start applying the update to each server by role.

***Note:  You MUST log on to each server role as a Local Administrator, SCOM Admin, AND your account must also have System Administrator role to the SQL database instances that host your OpsMgr databases.

My first server is a management server, and the web console, and has the OpsMgr console installed, so I copy those update files locally, and execute them per the KB, from an elevated command prompt:

This launches a quick UI which applies the update.  It will bounce the SCOM services as well.  The update usually does not provide any feedback that it had success or failure….  but I did get:

You can check the application log for the MsiInstaller events to show completion:

Log Name:      Application
Source:        MsiInstaller
Event ID:      1036
Computer:      SCOM1.opsmgr.net
Description:
Windows Installer installed an update. Product Name: System Center Operations Manager 2016 Server. Product Version: 7.2.11719.0. Product Language: 1033. Manufacturer: Microsoft Corporation. Update Name: System Center 2016 Operations Manager UR2 Update Patch. Installation success or error status: 0.

You can also spot check a couple DLL files for the file version attribute. 

Next up – run the Web Console update:

This runs much faster.   A quick file spot check:

Lastly – install the console update (make sure your console is closed):

A quick file spot check:

Or help/about in the console:

Additional Management Servers:

Windows Update contains the UR2 patches for SCOM 2016.   For my second Management Server – I will demonstrate that:

Then:

Updating Gateways:

Generally I can use Windows Update or manual installation.  I will proceed with manual:

The update launches a UI and quickly finishes.

Then I will spot check the DLL’s:

I can also spot-check the \AgentManagement folder, and make sure my agent update files are dropped here correctly:

***NOTE:  You can delete any older UR update files from the \AgentManagement directories.  The UR’s do not clean these up and they provide no purpose for being present any longer.

I can also apply the GW update via Windows Update:

Reporting Server Role Update

I kick off the MSP from en elevated command prompt, on my SSRS/SCOM Reporting role server:

This runs VERY fast and does not provide any feedback on success or failure.

Updating ACS (Audit Collection Services)

You would only need to update ACS if you had installed this optional role.

On any Audit Collection Collector servers, you should run the update included:

I thought it was interesting that the update says “OperationsManager 2012”…. it looks like this update is likely the same repackaged update for SCOM 2012 R2.

A spot check of the files:

2. Apply the SQL Scripts

In the path on your management servers, where you installed/extracted the update, there is ONE SQL script file: 

%SystemDrive%\Program Files\Microsoft System Center 2016\Operations Manager\Server\SQL Script for Update Rollups

(note – your path may vary slightly depending on if you have an upgraded environment or clean install)

Next – let’s run the script to update the OperationsManager (Operations) database.  Open a SQL management studio query window, connect it to your Operations Manager database, and then open the script file (update_rollup_mom_db.sql).  Make sure it is pointing to your OperationsManager database, then execute the script.

You should run this script with each UR, even if you ran this on a previous UR.  The script body can change so as a best practice always re-run this.

Click the “Execute” button in SQL mgmt. studio.  The execution could take a considerable amount of time and you might see a spike in processor utilization on your SQL database server during this operation.  

I have had customers state this takes from a few minutes to as long as an hour. In MOST cases – you will need to shut down the SDK, Config, and Monitoring Agent (healthservice) on ALL your management servers in order for this to be able to run with success.

You will see the following (or similar) output: 

IF YOU GET AN ERROR – STOP!  Do not continue.  Try re-running the script several times until it completes without errors.  In a production environment with lots of activity, you will almost certainly have to shut down the services (sdk, config, and healthservice) on your management servers, to break their connection to the databases, to get a successful run.

Technical tidbit:   Even if you previously ran this script in any previous UR deployment, you should run this again in this update, as the script body can change with updated UR’s.

3. Manually import the management packs

There are 30 management packs in this update!   Most of these we don’t need – so read carefully.

The path for these is on your management server, after you have installed the “Server” update:

\Program Files\Microsoft System Center 2016\Operations Manager\Server\Management Packs for Update Rollups

However, the majority of them are Advisor/OMS, and language specific.  Only import the ones you need, and that are correct for your language.  

This is the initial import list: 

What NOT to import:

The Advisor MP’s are only needed if you are using Microsoft Operations Management Suite cloud service, (Previously known as Advisor, and Operations Insights).

DON’T import ALL the languages – ONLY ENU, or any other languages you might require.

The Alert Attachment MP update is only needed if you are already using that MP for very specific other MP’s that depend on it (rare)

The IntelliTrace Profiling MP requires IIS MP’s and is only used if you want this feature in conjunction with APM.

So I remove what I don’t want or need – and I have this:

These import without issue.

4.  Update Agents

Agents should be placed into pending actions by this update for any agent that was not manually installed (remotely manageable = yes):  

If your agents are not placed into pending management – this is generally caused by not running the update from an elevated command prompt, or having manually installed agents which will not be placed into pending by design.

You can approve these – which will result in a success message once complete:

5.  Update Unix/Linux MPs and Agents

The “UR2” Linux MP’s and agents have been updated to align with UR2 for SCOM 2016.  You can get them here:

https://www.microsoft.com/en-us/download/details.aspx?id=29696

The current version of these MP’s for SCOM 2016 UR2 is 7.6.1072.0 – and includes agents with version 1.6.2-338

Make sure you download the correct version for your SCOM deployment:

Download, extract, and import ONLY the Linux/UNIX MP’s that are relevant to the OS versions that you want to monitor:

This will take a considerable amount of time to import, and consume a lot of CPU on the management servers and SQL server until complete.

Once it has completed, you will need to restart the Healthservice (Microsoft Monitoring Agent) on each management server, in order to get them to update their agent files at \Program Files\Microsoft System Center 2016\Operations Manager\Server\AgentManagement\UnixAgents

You should see the new files dropped with new timestamps:

Now you can deploy the agent updates:

Next – you decide if you want to input credentials for the SSH connection and upgrade, or if you have existing RunAs accounts that are set up to do the job (Agent Maintenance/SSH Account)

If you have any issues, make sure your SUDOERS file has the correct information pertaining to agent upgrade:

https://blogs.technet.microsoft.com/kevinholman/2016/11/11/monitoring-unixlinux-with-opsmgr-2016/

6.  Update the remaining deployed consoles

This is an important step.  I have consoles deployed around my infrastructure – on my Orchestrator server, SCVMM server, on my personal workstation, on all the other SCOM admins on my team, on a Terminal Server we use as a tools machine, etc.  These should all get the matching update version.

Review:

Now at this point, we would check the OpsMgr event logs on our management servers, check for any new or strange alerts coming in, and ensure that there are no issues after the update.

Known Issues:

1.  The OU property on Windows Computers only works if the computer object is in an actual OU and not the built in “Computers” container.  The problem is in a script in “Microsoft.SystemCenter.WindowsComputerPropertyDiscovery” datasource.

2.  The “PatchList” property on the HealthService doesn’t work.  This was re-written in PowerShell for SCOM 2016, and it looks like we still have a bug in the PatchList script.

3.  When running the update for ACS – it states the update is running for Operations Manager 2012.  The UI code was not updated as ACS is largely unchanged from SCOM 2012.

4.  If you use Windows Update to deploy the UR2 packages, you might see Windows Update fall into a loop where it re-applies these patches over and over.

One of the pain points in SCOM is keeping your agents up to date with your current UR level.

What makes this worse, is the view in the SCOM Console for “Agent Managed” where you could actually fix agents with a “repair” does NOT show you the UR level of the agent.

That has changed with this MP.

This management pack sample will disable the built in discovery for “Microsoft.SystemCenter.DiscoverHealthServiceProperties” which has a display name of “Discover Health Service Properties”

It will replace it with a new discovery that attempts to get the Agent Version from a file, that gets updated with every agent update.

***Note:  This discovery requires PowerShell on the agents in order to work.  If you still have old Windows Server 2003 or 2008 agents and have not installed PowerShell, it will simply not return updated version data for those.  This is not a concern for SCOM 2016, since all SCOM 2016 agents require PowerShell as a minimum requirement.  However, for SCOM 2012 R2 it is possible to have agents without PowerShell.  Those will simply retain their previous

In SCOM 2016, it will change this:

to this:

Now, you can sort by this column, and if you find agents that are not up to date, simply multi-select the agents you want to fix, and run a “Repair” against them:

If you multi-select, you just need to ensure all agents you are selecting report to the same Management Server, and have “Remotely Manageable” set to Yes.  If you want to change manually installed agents back to Remotely Manageable – see:  https://blogs.technet.microsoft.com/kevinholman/2010/02/20/how-to-get-your-agents-back-to-remotely-manageable-in-opsmgr-2007-r2/

This works in SCOM 2012 as well, with the caveat posted above about PowerShell:

You can download this addendum MP here:

https://gallery.technet.microsoft.com/SCOM-Agent-Version-b0bbdfb3