This is Part 8 in a series of posts described here:   https://blogs.technet.microsoft.com/kevinholman/2016/06/04/authoring-management-packs-the-fast-and-easy-way-using-visual-studio/

In our next example fragment – we will create Monitor for Windows Performance for our MP.

Step 1:  Download and extract the sample MP fragments.  These are available here:  https://gallery.technet.microsoft.com/SCOM-Management-Pack-VSAE-2c506737

I will update these often as I enhance and add new ones, so check back often for new versions.

Step 2:  Open your newly created MP solution, and open Solution Explorer.  This solution was created in Part 1, and the class was created in Part 2.

Step 3:  Create a folder and add the fragment to it.

Create a folder called “Monitors” in your MP, if you don’t already have this folder.

Right click Monitors, and Add > Existing item.

Find the fragment named “Generic.Monitor.Performance.ConsecSamples.TwoState.Fragment.mpx” and add it.

Select Generic.Monitor.Performance.ConsecSamples.TwoState.Fragment.mpx in solution explorer to display the XML.

Step 4:  Find and Replace

Replace ##CompanyID## with our company ID which is “Fab”

Replace ##AppName## with our App ID, which is “DemoApp”

Replace ##ClassID## with the custom class we created in Part 2 of the series.  This was “Fab.DemoApp.Class” from our previous class fragment.

Replace ##ObjectName## with a valid perfmon object.  I will use “Print Queue”

Replace ##CounterName## with a valid perfmon counter.  I will use “Total Jobs Printed”

Replace ##CounterNameWithoutSpaces## with your counter, but remove any spaces.  I will use “TotalJobsPrinted”

Replace ##InstanceName## with a valid perfmon instance.  I will use “_Total”

Replace ##Threshold## with a valid threshold for the monitor.  I will use “5”

That took all of 2 minutes.  Take another few minutes to review the XML we have in this fragment.  It is a simple monitor definition, it checks every minute, and when 5 consecutive samples are over a threshold value of “5”, it will change state and alert.   

Step 5:  Build the MP.   BUILD > Build Solution.

Step 6:  Import or Deploy the management pack.

Step 7:  Test the MP.

Open the Monitoring pane of the console – and find your folder you created in Part 6.

Open the state view.

Open Health Explorer for an instance of your class.

To test this perf counter, you can print dummy jobs from Notepad to the Microsoft XPS document writer, to get the value over the threshold.

After 5 consecutive samples, based on our interval (every 60 seconds) I should see a statechange after 5 minutes.

Boom:

These is an issue with the current Exchange 2010 Correlation Engine – which causes it to fail on SCOM 2012 or 2016 Management Servers.  Jimmy wrote about these here:

https://blogs.technet.microsoft.com/jimmyharper/2015/04/15/exchange-2010-correlation-engine-not-generating-alerts/

So one remedy to this – is to install the Correlation Engine (CE) on a non-management server role.  Either on a dedicated reporting server, or stand-alone server in the environment.  This is advisable – because the CE uses a LOT of memory – and we don’t want it consuming it all from the SCOM Management server.   One of the problems with this – is that the CE checks to ensure the SCOM 2007 (or later) console is installed when you kick off the MSI.  If it is missing – you get:

The problem with installing the SCOM 2012 Console, is that you end up with the wrong version of the SDK binaries that the CE is expecting.  To work around this – we can do a simple “hack”.  The alternative to this would be to install the SCOM 2007R2 console.  Many customers will not want to install this old console for no other reason.

The Exchange2010ManagementPackForOpsMgr2007-x64.msi is looking in the registry for:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup]
“UIVersion”=”6.0.6278.0”

We can simply create that “Setup” registry key, then a Reg String value for “UIVersion” with “6.0.6278.0” as the data value.

This will allow us to installed the CE.

Once installed – browse to the \Program Files\Microsoft\Exchange Server\v14\Bin directory.

Edit the Microsoft.Exchange.Monitoring.CorrelationEngine.exe.config file.

Here is the default file config:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <runtime>
        <generatePublisherEvidence enabled="false"/>
    </runtime>
    <appSettings>
        <add key="OpsMgrRootManagementServer" value="localhost" />
        <add key="OpsMgrLogonDomain" />
        <add key="OpsMgrLogonUser" />
        <add key="ManagementPackId" value="Microsoft.Exchange.2010" />
        <add key="CorrelationIntervalInSeconds" value="300" />
        <add key="CorrelationTimeWindowInSeconds" value="300" />
        <add key="AutoResolveAlerts" value="true" />
        <add key="EnableLogging" value="true" />
        <add key="MaxLogDays" value="30" />
        <add key="LogVerbose" value="false" />
        <add key="MaxLogDirectorySizeInMegabytes" value="1024" />
    </appSettings>
</configuration>

Modify the value for OpsMgrRootManagementServer to a management server (Might as well use your RMSe server).  Save the file.  UAC might block you from editing this file, if so – open notepad as elevated.

Next – open the Services.msc control applet, and configure the service “Microsoft Exchange Monitoring Correlation”

Set this service to run as your SDK account, or a dedicated service account that has rights to the SCOM SDK as a SCOM Administrator.

Your CE Service will be stuck in a restart loop.  It is crashing because of an exception – it is missing the SDK binaries.

Now – following the BLOG POST referenced above – unzip the three SCOM 2007 files in the blog attachment to the Program Files\Microsoft\Exchange Server\v14\Bin\ directory:

The errors should go away – and in the Application event log – you should see the following sequence:

Log Name:      Application
Source:        MSExchangeMonitoringCorrelation
Event ID:      700
Description:
MSExchangeMonitoringCorrelation service starting.

Log Name:      Application
Source:        MSExchangeMonitoringCorrelation
Event ID:      722
Description:
MSExchangeMonitoringCorrelation successfully connected to Operations Manager Root Management Server.

Log Name:      Application
Source:        MSExchangeMonitoringCorrelation
Event ID:      701
Description:
MSExchangeMonitoringCorrelation service started successfully.

Resource pools are nothing new – they were introduced in SCOM 2012 RTM, for two reasons:

1.  To remove the single-point-of-failure that was the RMS role in SCOM 2007.

2.  To provide a mechanism for high availability of agentless/remote workflows, such as Unix/Linux, Network, and URL monitoring, among others.

That said – they are often not fully understood.

Lets talk about the primary components of a Resource Pool.  I am going to “dumb this down” a lot…. because it is actually quite complex behind the scenes.  So I will break this down more into “roles” with regard to Resource Pools.  The primary “role” components we will discuss are:

1.  Members

2.  Observers

3.  Default Observer

Members of a pool are either a Management Server or a Gateway Server. 

Observers are “observer-only” roles.  These will be a Management Server or a Gateway server, that do NOT participate in loading workflows for the pool, however they participate in quorum decisions.  This is actually pretty rare to do anything with Healthservice based observer-only roles…. but you would use these if you wanted high availability for your pool, but only a limited number of Healthservices actually running pool workflows.  This is rarely used under normal circumstances.

Default Observer is the SCOM Operations Database.  This is set to “Enabled” or “Disabled” for every pool, and this is enabled for all pools by default.  The “reason” this exists is for the following:

To allow for a pool to have high availability when you have two management servers in a pool

Let’s talk about that.

A pool requires ONE or more members.

A pool requires THREE (quorum voting) members to establish high availability.

High availability is the ability to have a member be unavailable, with no loss of monitoring.

The reason we need THREE (quorum voting) members (not two) for high availability is because of the quorum algorithm.  We require that MORE than 50% of the quorum voting members in a pool be available.  If you have only two members of a pool, and one is down, you have lost quorum, because of the “greater than 50%” rule.

Therefore – the “Default Observer” was dreamed up, so customers would not HAVE to deploy a minimum of THREE management servers just to get high availability for their Resource Pools.  It is a special quorum voting “observer” role, to allow for high availability of pools when you have two management servers deployed.  This reduced cost and complexity for a basic SCOM deployment.

Lets break this into “scenarios”

Single Management server in pool

The default observer is enabled by default.

There is no high availability, because the management server is a single point of failure.

The default observer provides no benefit (nor harm) in this case.

Two management servers in pool

The default observer is enabled by default.

There is high availability for the pool, because there are three voting members (2 MS + Default Observer)

If you disable the default observer, you will lose high availability for the pool.

Three management servers in pool

The default observer is enabled by default.

There is high availability for the pool, because there are four voting members (3 MS + Default Observer)

By default – you can only have ONE management server down, to maintain the pool. (greater than 50% rule) because if two MS are down, this is 50% of voting members, so pool suicides.

The default observer in this case provides NO value.  It does not increase the number of management servers that can be down, therefore it does not increase pool stability.

You can consider removing the DO (Default Observer) in this scenario.

Four management servers in pool

The default observer is enabled by default.

There is high availability for the pool, because there are five voting members (4 MS + Default Observer)

By default – you can only have TWO management server down, to maintain the pool. (greater than 50% rule) because if three MS are down, this is greater than 50% of voting members, so pool suicides.

The default observer in this case provides significant value, because it increases the number of management servers that can be down.  Without the DO in this case, you’d only have 4 quorum members, which only allows for ONE to be unavailable.

Five or more management servers in pool

The default observer is enabled by default.

There is high availability for the pool, because there are 6 voting members (5 MS + Default Observer)

By default – you can only have TWO management server down, to maintain the pool. (greater than 50% rule) because if three MS are down, this is exactly 50% of voting members, so pool suicides.

The default observer in this case provides NO value.  It does not increase the number of management servers that can be down, therefore it does not increase pool stability.

You can consider removing the DO (Default Observer) in this scenario.

One could argue – that once you have 3 or more management servers in a pool, any “odd” number of management servers would be a good consideration to remove the DO from the pool.  I’d also argue that once you hit 5 management servers, you are probably big enough that the database is under significant load (you wouldn’t typically have 5 management servers in a small environment).  When the database is under heavy load, the default observer might not perform well, and might experience latency in resource pool calculations/voting.

The way the default observer plays a role – is that each MANAGEMENT SERVER in the pool, queries its own local SDK service – which allows it to get data from the database.  There is a table in the SCOM Operations database for the default observer.  So if the SDK service is under load, or the database, we could experience latency that otherwise would not exist.

Gateways as resource pool members

Next – we should discuss the Gateway role as it pertains to Resource Pools.  Microsoft support resource pool membership for Management Servers, AND for Gateway servers. 

For instance, a customer might monitor Unix/Linux servers in a firewalled off DMZ, or across a small WAN circuit where you want the agentless communication localized.  In this scenario, a customer might create dedicated resource pools for Gateways in those locations, to perform monitoring.

Single Gateway server in pool

The default observer is enabled by default.

There is no high availability, because the Gateway server is a single point of failure.

The default observer should NOT be used here, because Gateways do not have a local SDK service, therefore they cannot query the database.

Two Gateway servers in pool

The default observer is enabled by default.

One would THINK there is high availability for the pool, because there are two GW’s in the pool, right?  HOWEVER – that is NOT the case.  As we discussed above – we need three voting members to establish high availability for a pool.  Since the Default Observer is NEVER valid for a pool consisting of Gateways, there are only TWO members of this pool.  The pool will run, and will load balance workflows, but if either pool member goes down, the pool suicides.  In this case – you actually have WORSE availability than if you placed a single member in the pool!

In order to maintain high availability for a pool made of Gateways, you need to have THREE GW’s in the pool.

The default observer should NOT be used here, because Gateways do not have a local SDK service, therefore they cannot query the database.

Three Gateway servers in pool

The default observer is enabled by default.

There is high availability for the pool, because there are three voting members (3 GW)

By default – you can only have ONE Gateway server down, to maintain the pool. (greater than 50% rule) because if two GW are down, this is >50% of voting members, so pool suicides.

The default observer should NOT be used here, because Gateways do not have a local SDK service, therefore they cannot query the database.

Let’s take a minute and process this.

What we have learned, is that you should remove the DO from any pool comprised of Gateways.

You should consider removing the DO from pools when 5 or more Management Servers are present.

If your pools are stable….. and you aren’t having any problems with high availability….. then this really doesn’t make much difference….. which is why the defaults are set like they are.

So we have talked about pool members, and the default observer…… but what about the “observer” role?

This role is really unique, and will not be used very often.  I cannot think of a single enterprise deployment where I have seen it used.  Generally speaking – if we are adding a dedicated observer for a pool (which is a management server or a GW server) then why not just make that server a full blown pool member?

There is only one scenario where I can think of where this might be useful.  Such as a company with a datacenter with SCOM deployed.  In the SAME DATACENTER, they have a DMZ with two gateways deployed because of firewall rules.  In this case, you could potentially make their parent management server a dedicated observer only, and this would work because tcp_5723 is open already for Healthservice communication.  This is incredibly rare, and the best practice would be to just go ahead and plan for three Gateways servers in the DMZ.

Remember – for resource pool members – Microsoft supports Management Servers and Gateways.

For resource pool observers – the same, Management Servers and Gateways.

That said – I have done some testing making an *agent* a dedicated observer, such as the DMZ scenario above, and it does work.  The agent becomes a voting member for quorum, and high availability is created by this.  Microsoft didn’t plan or test this scenario – so it is technically unsupported.

Which got me to thinking – “what it I create a resource pool, and make its membership strictly agents”???

Well, that works too.  You cannot do this using the UI, but you can in PowerShell.  I create a resource pool of only agents, then set up URL monitoring to that pool, and high availability and load distribution worked great.  Again, not technically supported by Microsoft, but a unique capability nonetheless.

Lastly – I will demonstrate some PowerShell commands to work with this stuff.

To disable the default observer for a pool:

$pool = Get-SCOMResourcePool -DisplayName "Your Pool Name"
$pool.UseDefaultObserver = $false
$pool.ApplyChanges()  

To add or remove Management Servers or Gateways from a manual pool:

$pool = Get-SCOMResourcePool -DisplayName "Your Pool Name"
$MS = Get-SCOMManagementServer -Name "YourMSorGW.domain.com"
$pool | Set-SCOMResourcePool -Member $MS -Action "Add"
$pool | Set-SCOMResourcePool -Member $MS -Action "Remove"

To add or remove Management Servers or Gateways as Observers only to a pool:

$pool = Get-SCOMResourcePool -DisplayName "Your Pool Name"
$Observer = Get-SCOMManagementServer -Name "YourMSorGW.domain.com"
$pool | Set-SCOMResourcePool -Observer $Observer -Action "Add"
$pool | Set-SCOMResourcePool -Observer $Observer -Action "Remove"

If you want to play with adding AGENTS as a resource pool member or observer (not supported) then simply change “Get-SCOMManagementServer” above – to “Get-SCOMAgent”

Credits:

A debt of gratitude to Mihai Sarbulescu at Microsoft for his guidance on this topic – he has forgotten more about Resource Pools than most people at Microsoft ever knew. 

Customers often use “My Workspace” to create customized views that they use on a regular basis.  However, one of the drawbacks on My Workspace is that these views are not available to any other users. 

Generally, we recommend customers use My Workspace to test and develop views, then simply re-create them in a Management Pack when they are happy with the results.  But what if you wanted to just forklift them from My Workspace, into a MP programmatically?

This isn’t simple – because of how these views are stored.  You can access these views in the database with the following query:

SELECT
  ss.UserSid,
  ss.SavedSearchName AS 'ViewDisplayName',
  vt.ViewTypeName,
  mpv.Name AS 'MPName',
  ss.ConfigurationXML
FROM SavedSearch ss
  INNER JOIN ViewType vt ON ss.ViewTypeId = vt.ViewTypeId
  INNER JOIN ManagementPackView mpv on vt.ManagementPackId = mpv.Id
WHERE
  ss.TargetManagedTypeId is not NULL

This will yield output like so:

From this, you can either manually copy and paste this data into a management pack, or you could event build an MP snippet to take this data as input from a CSV, based on the query output.  https://blogs.technet.microsoft.com/kevinholman/2014/01/21/how-to-use-snippets-in-vsae-to-write-lots-of-workflows-quickly/

Here is a simple MP example where you could manually copy and paste the My Workspace data into:

<?xml version="1.0" encoding="utf-8"?><ManagementPack ContentReadable="true" SchemaVersion="2.0" OriginalSchemaVersion="1.1" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <Manifest>
    <Identity>
      <ID>Demo.Views</ID>
      <Version>1.0.0.0</Version>
    </Identity>
    <Name>Demo - Views</Name>
    <References>
      <Reference Alias="SC">
        <ID>Microsoft.SystemCenter.Library</ID>
        <Version>7.0.8433.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="System">
        <ID>System.Library</ID>
        <Version>7.5.8501.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
    </References>
  </Manifest>
  <Presentation>
    <Views>
      <View ID="View.1" Accessibility="Public" Enabled="true" Target="System!System.Entity" TypeID="SC!Microsoft.SystemCenter.AlertViewType" Visible="true">
<!-- In the line above change the following:
    Change the View ID to something unique in this MP for each view you create
    Change the MP reference alias (SC!) to match a reference MP seen in MPName
    Change the ViewType example (Microsoft.SystemCenter.AlertViewType) from ViewTypeName
-->
        <Category>Custom</Category>
<!-- Insert your query data ConfigurationXML below this line  -->



<!-- Insert your query data ConfigurationXML above this line  -->
      </View>
    </Views>
    <Folders>
      <Folder ID="Demo.Views.Root.Folder" Accessibility="Public" ParentFolder="SC!Microsoft.SystemCenter.Monitoring.ViewFolder.Root" />
    </Folders>
    <FolderItems>
      <FolderItem ElementID="View.1" ID="ib42bd9704bf54df0a6c18c9f5c1614ca" Folder="Demo.Views.Root.Folder" />
    </FolderItems>
  </Presentation>
  <LanguagePacks>
    <LanguagePack ID="ENU" IsDefault="false">
      <DisplayStrings>
        <DisplayString ElementID="Demo.Views">
          <Name>Demo - Views</Name>
        </DisplayString>
        <DisplayString ElementID="Demo.Views.Root.Folder">
          <Name>Demo - Views</Name>
        </DisplayString>
        <DisplayString ElementID="View.1">
          <Name>All Alerts</Name>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
  </LanguagePacks>
</ManagementPack>

As you can see, it is a lot of work, not something I’d want to do on a regular basis…. but if you had this as a requirement, it’s possible! 

These are now available:

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

This is version 10.0.8.0.  It covers the Windows Server 2016 MP release ONLY, and does not include other management packs for previous operating systems, which will be interesting to see how the product group combines these in future updates, since they share the same base libraries.

Check out the guide – there are MANY updates in this release from the previous technical preview MP’s, so you can tell the product team has been hard at work on these.

All the management packs are supported on System Center 2012, System Center 2012 R2 and System Center 2016 Operations Manager.
Please note that Server Nano monitoring is supported by SCOM 2016 only.

Changes in Version 10.0.8.0
•    Added two new object types (Windows Server 2016 Computer (Nano) and Windows Server 2016 Operation System (Nano)) and a new group type (Windows Server 2016 Computer Group (Nano)). This improvement will help users to differentiate the groups and object types and manage them more accurately.
•    Added a new monitor: Windows Server 2016 Storport Miniport Driver Timed Out Monitor; the monitor alerts when the Storport miniport driver times out a request.
•    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 with Windows Server 2016 Operating System BPA Monitor: it did not work.
•    Fixed bug with incorrect discovery of Windows Server Operating System on Windows Server 2016 agentless cluster computers occurring upon management pack upgrade. See Troubleshooting and Known Issues section for details.
•    Fixed bug: Free Space monitors did not work on Nano Server.
•    Changed the logic of setting the override threshold values for Free Space (MB and %) monitors: a user 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.
•    Fixed localization issue with root report folder in the Report Library.
•    Fixed bug: Windows Server 2016 Computer discovery was causing repeated log events (EventID: 10000) due to improper discovery of non-2016 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.
•    Due to incompatibility issues in monitoring logic, several Cluster Shared Volumes MP bugs remained in version 10.0.3.0. These are now fixed in the current version (see the complete list of bugs below). To provide compatibility with the previous MP versions, all monitoring logic (structure of classes’ discovery) was reverted to the one present in version 10.0.1.0.
o    Fixed bug: disk free space monitoring issue on Quorum disks in failover clusters; the monitor was displayed as healthy, but actually it did not work and no performance data was collected.
o    Fixed bug: logical disk discovery did not discover logical disk on non-clustered server with Failover Cluster Feature enabled.
o    Fixed bug: Cluster Shared Volumes were being discovered twice – as a Cluster Shared Volume and as a logical disk; now they are discovered as Cluster Shared Volumes only.
o    Fixed bug (partially): mount points were being discovered twice for cluster disks mounted to a folder – as a cluster disk and as a logical disk. See Troubleshooting and Known Issues section for details.
o    Fixed bug: Cluster Shared Volume objects were being discovered incorrectly when they had more than one partition (applied to discovery and monitoring): only one partition was discovered, while the monitoring data was discovered for all partitions available. The key field is changed, and now partitions are discovered correctly; see Troubleshooting and Known Issues section for details.
o    Fixed bug: Windows Server 2008 Max Concurrent API Monitor did not work on Windows Server 2008 platform. Now, it is supported on Windows Server platforms starting from Windows Server 2008 R2.
o    Fixed bug: when network resource name was changed in Failover Cluster Management, the previously discovered virtual computer and its objects were displayed for a short time, while new virtual computer and its objects were already discovered.
o    Fixed bug: performance counters for physical CPU (sockets) were collected incorrectly (for separate cores, but not for the physical CPU as a whole).
o    Fixed bug: Windows Server 2016 Operating System BPA monitor was failing with “Command Not Found” exception. Also, see Troubleshooting and Known Issues section for details on the corresponding task.
o    Fixed bug: View Best Practices Analyzer compliance task was failing with exception: “There has been a Best Practice Analyzer error for Model Id”.
o    Fixed bug: in the Operations Console, “Volume Name” fields for logical disks, mount points, or Cluster Shared Volumes were empty in “Detail View”, while the corresponding data was entered correctly.
o    Fixed bug: Logical Disk Fragmentation Level monitor was not working; it never changed its state from “Healthy”.
o    Fixed bug: Logical Disk Defragmentation task was not working on Nano Server.
o    Fixed bug: If network resource name contained more than 15 symbols, the last symbols of the name was cut off, which was resulting in cluster disks and Cluster Shared Volume discovery issues.
o    Fixed bug: Logical Disk Free Space monitor did not change its state. Now it is fixed and considered as deprecated.
•    The Management Pack was checked for compatibility with the latest versions of Windows Server 2016 and updated to support the latest version of Nano Server.
•    Added new design for CPU monitoring: physical and logical CPUs are now monitored in different way.
•    Updated Knowledge Base articles and display strings.
•    Improved discovery of multiple (10+) physical disks.
•    Added compatibility with Nano installation.

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-19-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?)