Microsoft Operations Manager and OMS

MP Author Version 8.2

The following is a special guest blog from Silect

We are pleased to announce the General Availability of MP Author version 8.2. We’ve made lots of updates and improvements to our family of products for SCOM. Here’s a summary of the changes to MP Author:

  • Support for SCOM 1801
  • When sealing and deploying and MP, deploy the sealed MP, not the unsealed.
  • Remember the last SCOM version used when creating an MP, as it should be the default next time. Improve display and logging of the versions of reference MP that are loaded.
  • Groups can now be created without dynamic membership rules.
  • Improved impersonation when browsing remote registries.
  • When parsing scripts for class names, parameters, etc. allow both single and double quotes.
  • When displaying lists of targets, ensure the list shows abstract and singletons if needed.
  • Several dialogs and message boxes now allow you to not show them again (once you know what they are telling you, you can select a “Don’t Show This Again” check box.)
  • Discoveries can now be enabled for a group from within the wizard.
  • Alert, Event, Performance and State views can now be filtered by a group.
  • Editing event, performance, service or process rules/monitors will work correctly even if the machine being browsed doesn’t have the items previously selected.
  • Performance monitors now support two and three-state monitors using simple values, average values, delta values, or consecutive samples.
  • Script monitors and rules allowed overrides on the parameter values but did not use the override value. This has been corrected.
  • Setting a description for an element which does not have a display name failed. The new behaviour is to set the missing display name (to the actual name) at the same time.
  • Do not require hosted classes with no key properties to be singletons because the hosting class may have key properties.
  • Improve handling of reference MPs which don’t exist or are the wrong version.
  • Allow registry and WMI queries to work if they contain characters which are significant in XML (like < or >).
  • The script class wizard will no longer allow users to change the class name, if the class name was determined from the script (if they don’t match, the discovery will fail).
  • Numerous bug fixes, UI and performance improvements

In case you missed it! The latest System Center release, version 1801, is here.

In February we announced that System Center, version 1801 was now available.  It’s the first release in our new Semi-Annual Channel and delivers new features and enhancements based on customer feedback. It builds on the capabilities of System Center 2016 and has support for the latest version of Windows Server, version 1709 as well as Windows Server 2016. It includes enhanced Linux monitoring support, more efficient VMware backup, and improved user experience and performance. For more details, read the full announcement..

System Center 1801 Operations Manager – Enhanced log file monitoring for Linux Servers

System Center Operations Manager 1801 has enhanced log file monitoring capabilities for Linux Servers.

  • Operations Manager now supports Fluentd, an Open source Data collector.
  • Customers can also leverage Fluentd capabilities and plugins published by the Fluentd community to get enhanced customizable log file monitoring.
  • The existing OMI based monitoring for currently supported Linux workloads will continue to work as it is today. 

With this release we have added support for the following log file monitoring capabilities

  • Support for wildcard characters in log file name and path.
  • Support for new match patterns for customizable log search like simple match, exclusive match, correlated match, repeated correlation and exclusive correlation. We have released 6 new filter plugins for customizable log search.
  • Support for generic Fluentd plugins published by the fluentd community. System Center Operations Manager 1801 would include a convertor plugin which would convert the fluentd data from generic plugins to the format specific for SCOM log file monitoring.

Below are few architectural changes in the SCOM Management server and the SCOM Linux agent to support Fluentd.

The new Linux SCOM agent would include a Fluentd agent (as shown in the above picture (1)).

Users would define the log file names, match pattern and the event to be generated on pattern match along with the event description in the Fluentd Configuration file.

On match of a log record, Fluentd would send the event to the System Center Operations Manager External Datasource service on the SCOM Management Server / Gateway (2).This is a Windows REST based service which would receive the event and send it to a dedicated custom Event log channel Microsoft.Linux.OMED.EventDataSource (3).

User would need to import a management pack (4) which would look for events in this custom event channel and generate alerts accordingly

User Workflow:

On Linux Server:

On SCOM Management Server:

User needs to follow the below steps on the Management Server 


Step 1:

User would need to import the latest Linux Management pack (shipped with the SCOM 1801 binaries) and install the new SCOM agent on the Linux Servers.

Users can install the agent either manually or through discovery wizard (recommended). For detailed steps, refer here.

Step 2:

Author Fluentd configuration file and place it on the Linux Servers

Customers need to author a Fluentd configuration file and can use any of the existing enterprise tools like Chef/Puppet to place the configuration file to the Linux server.

Recommended practice is to copy the configuration into /etc/opt/microsoft/omsagent/scom/conf/omsagent.d directory on all Linux servers and include the configuration file directory as @include directive in the master configuration file /etc/opt/microsoft/omsagent/scom/conf/omsagent.conf

The Fluentd configuration file is where the user should define the input, output and the behavior (match processing) of Fluentd. This is done by defining the following in the configuration file:

Source directive:

Fluentd’s input sources are defined in the source directive using desired input plugins. Users would need to define the log file names along with the file path here in this directive. Wild card characters are support both in file name and path.

Filter directive:

Filter directive is the chained processing pipeline. Users would need to define the match pattern and the events that are to be generated on a match here in this section. We have released the following filter plugins with this release

  • filter_scom_simple_match,
  • filter_scom_excl_match
  • filter_scom_cor_match
  • filter_scom_repeated_cor
  • filter_scom_excl_correlation
  • filter_scom_converter
Match directive:

Users define the output processing in Match directive. We have released “out_scom” match plugin which would send the events generated by Fluentd to the System Center Operations Manager External Datasource service on the SCOM Management Server/Gateway.

For more detailed instructions on how to author a Fluentd configuration file, refer here.

Step 3:

On SCOM Management server: Import Management pack and enable OMED Service

On Management Server User needs to do the following:

1)      Start OMED service (refer here).

2)      Import Management pack for log file monitoring.

User can import the sample Management pack (reference here ), save this as an xml file and import it in SCOM console. This Management pack has a rule that looks for all events from the new data source Microsoft.Linux.OMED.EventDataSource and generates alerts accordingly. The Alert severity and priority are set in the management pack. The Alert description is obtained from the event description which would be defined by the user in the Fluentd configuration file.

If users are interested to generate alerts only for specific events generated, they could author their own custom management pack using VSAE.

Example Scenario:

User would like to monitor the following scenarios

1)      Apache http server URL monitoring

Scenario: Monitor a web URL hosted on Apache http server and generate alerts on SCOM Management server if the URL has any issues.

Log to be monitored: User monitors Apache http server access.log for error code. If the log receives any code other than 200 (success code) an event will be sent to SCOM Management Server.

2)      Authentication failure

Scenario: If a user tries to access a server more than 5 times with an incorrect password, an alert would be sent to the SCOM server alerting an unauthorized user trying to intrude.

Log to be monitored: User monitors Linux Server auth.log for authentication failure error messages. If the messages exceeds 5 times in 10 seconds and event will be sent to SCOM Management server.

Sample Configuration File:

The OMEDService on SCOM Management server would receive an event on match of a log record along with the log record context. User would need to import a management pack on SCOM server which would generate alert when there is an event received from Linux Server.

Events on the SCOM Management Server:

 Generated Alert on the Management Server:

The Alert context will contain the log record which will have more details on the error code received while trying to access the URL.

Other Sample User Scenarios:

For more detailed steps look at the online documentation.


We’d love to hear your feedback on this new feature. Feel free to send your feedback to