What are the new features in SCOM 2019 UR3

by

Last night Microsoft released System Center 2019 Update Rollup 3 (UR3) which was mentioned here, and with it came SCOM 2019 UR3. Earlier today I wrote about the download location and what fixes are included in SCOM 2019 UR3 and that many of them are fueled by SCOM User Voice and of course cases created with support.

In this post I want to focus on what is NEW in SCOM 2019 UR3 in the new features and improvements made.

First of all a link to Microsoft page about all SCOM new features for all the Update Rollups in SCOM 2019 so far for an overview. I will be diving into some of them more deeply below.

The list!

Change tracking

In the previous UR2 rollup a number of change tracking reports were introduced, which included

  • Change tracking for Management Packs showing packs imported or removed or updated to different versions
  • Changes to Management pack objects (monitors, rules, groups)
  • Changes to Overrides

In Update Rollup 3 we are now seeing the following added:

  • Change tracking for agents, which include install/uninstall/repair/upgrade actions. Agent Tracking.
  • Change tracking for monitor health reset actions. Monitor Health Reset Tracking.

These reports can be found in the SCOM reporting pane in the folder Microsoft Generic Report Library with their names listed above at the end of each bullet point in the list.

Also, some database changes related to change tracking:

  • There is a rule called Data Warehouse Job Status Information synchronization and it is responsible to move the change tracking data from OpsDB to DW db.
  • There is a rule called Data Warehouse Job Status Information Grooming which handles grooming of the change tracking data in the Data Warehouse, where you can override the number of days retention for change tracking data related to Agents and Monitor Resets.

What does the change tracking for agents look like?

Well, I ran a new report this morning after a push of some UR3 updates to agents with some expected fails.

What we can see here is in the most right column I was logged into the SCOM console with the administrator account (this is a demo environment). And in the case of the last update I entered other credentials, causing the update to fail. SO you can see who was logged on and which credentials were being used.

The rest of the columns speak for themselves I guess. The date and time of the action, which type it was (install/upgrade/uninstall/repair), and the status. Also that these actions were for Windows agents in this case.

What does the change tracking for Monitor Health Reset look like?

This morning I did a few health resets of monitors from the health explorer and ran the report:

We can see from here which monitors got reset and of which type they are. the target and if it failed or not. And the user logged into the SCOM console who was resetting the health state of those monitors.

For more information about the change tracking feature see this page.

 

Additional view options in web console widgets

Starting from SCOM 2019 UR3 you can now also sort the results columns in the Alert widget and State widget and group them.

For more information see this page.

 

Disabled SSL renegotiation for Linux Agent

Starting SCOM 2019 UR3 the Linux agent SSL renegotiations are disabled by default. This is to avoid creating a security vulnerability where an attacker could create a denial of service by performing many renegotiations against a single connection.

For more information regarding this item see this page.

 

Dynamic changes in log-level settings without agent restart

With Operations Manager 2019 UR3 and later, you can change the log-level settings without restarting the OMI agent. For more information see the following page. This relates to the Unix/Linux agent. You can set the logging level in the omiserver.conf  file and next apply the new log level by running

$sudo /opt/omi/bin/omiconfigeditor –reconfig

 

Resolved issues with orphaned alerts

In earlier releases, active alerts did not get closed after non-persistent health state in failover scenarios. Overall, health service doesn’t hold the last state of the monitor; alerts are not closed while resetting the monitor to healthy. With Operations Manager 2019 UR3 and later, all of the orphaned alerts are closed, eventually, depending on the type of monitor. Learn more. These things could happen while a management server had a failover or reconnected itself. Or for example if the health service cache was cleared. This could have led to an alert sitting in SCOM coming from a monitor and the alert would not go away anymore.

 

Support for RHEL 6

Operations Manager 2019 UR3 and later supports RHEL6 via RHEL6 management pack. This has been long asked, because many customers still run RHEL 6. To give you some context, RedHat also has something similar to Microsoft support statement, whereby there is mainstream support for x years and extended support for x years. For Microsoft Windows Server this is usually 5 years for each. Now Microsoft can not just support a product from another vendor , where the other vendor does not have it in mainstream support. So this limited the story to 5 years only for RedHat for example. Quite logical, however many customers were not ready to move their RedHat 6 up to version 7 or 8 yet in the past two years and it prevented them from moving to SCOM versions where this agent version is no longer supported. Well, not without workarounds which we talked about before. Now RHEL 6 is brought back into the story. Learn more. Very happy with that, as this was a common User Voice request.

 

TLS 1.2 support for Solaris 10 SPARC

Operations Manager 2019 UR3 and later supports TLS 1.2 for Solaris 10 SPARC. Learn more.

 

Performance

And the next item is about performance improvements, which I know is always on the mind of SCOM Admins and Operators. SCOM is I think the best monitoring product out there, but with its flexibility comes some delay as well while working with the console. I am very happy the Product Team has been taking this seriously and every UR and every LTSB version of SCOM we now see performance improvements in views, queries, dll’s and so on to cover SCOM console, web console and other connection sources.

 

Performance improvements in Operations Manager

Operations Manager 2019 UR3 provides performance improvement in the following scenarios:

  • Improvements in load time for Windows computer view

    Windows computer view in Operations Manager console was taking unreasonable time to load.

    With Operations Manager 2019 UR3, to decrease the load time for this view, we optimized the relevant SQL query.

  • Improvement in load time while changing user role privileges

    Prior to 2019 UR3, any changes to a user’s role privileges (for example, providing or revoking permissions on specific views or dashboards) was taking about 30 minutes.

    With Operations Manager 2019 UR3, the SQL queries that fetch the relevant data and helps change the settings of a user role are optimized. This optimization has led to significant improvements in the load time.

  • Grooming of maintenance mode staging table

    In earlier releases, Operations Manager Data warehouse grooming (emptying) of maintenance mode staging table was not occurring. The table increased every day into millions of rows, which eventually filled up the database that could potentially lead to additional cost to spin up a new database. The increase in utilization of database is usually correlated with decrease in performance of Operation Manager’s console.

    With Operations Manager 2019 UR3, an index is added to the maintenance mode staging table; grooming of the table occurs now.

  • Improvement in SDK services

    Operations Manager console was taking longer time to load and complete basic tasks.

    With Operations Manager 2019 UR3, we optimized relevant SQL queries and the performance has significantly improved now.

  • Reliability and performance improvement in Xplat agent

    In Operations Manager 2019 UR3, heartbeat threads are isolated from performance data related threads, so any malfunctioning in performance providers would not affect heartbeat request, thereby improving reliability of Operations Manager.

    Filters are also introduced in Xplat management packs to help you customize the discovery and monitoring scope of the entities of interest; further to improve performance and scale of Xplat agent.

 

Now, lets dive into the upgrade as listed here and very happy monitoring!

Bob Cornelissen