Any idea when is RHEL 8 going to be supported? My customers are already deploying servers in RHEL8 and we cannot provide monitoring for them.

Support for container monitoring in SCOM.

Currently default directory for agent installation on Unix/Linux servers using Operations Console is /tmp/scx-username. However, if /tmp directory is hardened due to security reasons for unix/linux servers on customer environment, they will have to manually install scom agent on unix/linux servers and does not have an alternative to install the agent from Operations console on other directory.

I was reviewing the supported UNIX/Linux OSs at the following location:https://docs.microsoft.com/en-us/system-center/scom/plan-supported-crossplat-os?view=sc-om-2019 and took note that support for HP-UX has been removed. This is creating a problem for my current customer since they use HP-UX and will continue to use HP-UX. According to my customer HP-UX is still supported through 2025, so removing monitoring support in SCOM 2019 is going to be a problem. While I understand there may be workarounds for this issue, I am also concerned about maintaining the customer's environment in a supported configuration.

In addition to developing the PKI Certificate Monitoring MP directly and not having to rely on 3rd party, add the ability to monitor PKI Certificates in Unix/Linux environments.

The ability for SCOM Operations Manager to monitor when a Linux file system goes into read only mode

When you create a Linux Monitor the default data type is String, then when your script receive a Integer data (for example) the linux monitor doesn't work properly

need to update help documents for new version of unix/linux management packs. we never come to know what are fixes released or newly introduced with latest version of MP's

Client for BE "Big Endian" Red Hat.

We has been approached by our UNIX Team and they would like to know how soon we can on-boarding REHL8 Server for monitoring through SCOM 2016 UR5. we have invested time to find out relevant information over the internet, but could not find anything and that is the reason why we have raise case with Microsoft REG:119051521002564 for same.

We generally check the catalog regularly for updated Management Packs in SCOM 2012 R2. The catalog is currently showing what appear to be incorrect versions of the MPs for the customers still on 2012 R2:

It might be a good idea to correct this, since these versions will break UNIX/Linux monitoring in SCOM 2012 R2, at the very least agent deployment will be broken.

SCOM 1807 monitoring Oracle Linux %used memory. What is displayed on the dashboard and performance charts are not the same as seen on the server itself. Please see thread https://social.technet.microsoft.com/Forums/systemcenter/en-US/99c37ed5-82a6-487a-95af-3e094effca7a/linux-memory-monitoring?forum=operationsmanagerunixandlinux for a description of the issue.

At current time, the Unix agent for SCOM 2012 R2, 2016 and 1801 requires that the agent software run with root user credentials. Any software that runs directly as the root user is a security risk.

I'd like to see a future version of the SCOM Unix Agent that could run as a non-root user, with elevated privileges, so that the agent can properly monitor the Unix client while minimizing security risks.

This feature is intended for triggering maintenanace mode from Linux agent system with superuser previliges.

Add OS discovery "SUSE Linux Enterprise Server 12 for .SAP" to default Linux management pack. Currently the Attribute caption is hardcoded "SUSE Linux Enterprise Server 12". Discovery of SLES for .SAP is not possible, OS shown as "Unknown"

Currently there is no way to leverage a built in RunAs account that is pre-configured in SCOM to use Invoke-SCXDiscovery cmdlet, while it is possible to reference that when pushing an agent via the console. Inability to rely on SCOM RunAs accounts requires keeping another copy of the credentials together with the script, which in turn adds some overhead with regards to keeping those creds secure and in consistence with the SCOM store.

Please see forum thread here:

https://social.technet.microsoft.com/Forums/systemcenter/en-US/57f86c23-9eac-409c-8bbc-6ad550c524e5/unixlinux-universal-agent-and-fips-compliance?forum=operationsmanagerunixandlinux

Per the MSFT team member Steve Weber:

I can reproduce this in our lab and we do not currently support FIPS and there is no workaround without disabling FIPS on the system. If this is something you want supported with the SCOM UNIX/Linux agents, please open a ticket with Microsoft support and have them create a 'Design Change Request' [DCR] so that it gets escalated and pushed back to our team.

I will also pass this post on to our management so they have reference but the DCR will be your quickest results.

In the Windows Monitoring the Management Pack has two different monitors, which monitor "heartbeat failure" and "Computer not reachable".
In the Unix/Linux monitor you only provide a heartbeat monitor that run automatically the Task for an ICMP ping. We also need the monitorinformation if the System is not reachable because this is an important information for the Unix/Linux admins.