Monitoring of SLES 15 systems is currently not possible with SCOM 2016. Please provide an agent and management pack to monitor SLES 15 systems with SCOM 2016 at the same level as SLES 11 and 12.

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

When a Management Server (or Gateway) is rebooted, all UNIX/Linux-based monitor health states are reset, resulting in the subsequent re-generation of a slew of alerts for all related x-plat agents

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.

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.

Make us be able to use wildcards in the log file path of the "UNIX/Linux Log File Monitoring"-template.

Mounted disks are not discovered, you should have an option to do this

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"

we should focus towrards unix monitoring like we need enhance it for Docker and Linux certificate monitoring. And should also closly work on office 365 momitoring.

I am working with 2 clients and Linux monitoring is not at that par good and office 365 too.

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

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.

Could SCOM 2012 monitor the Linux server (CentOS) through SNMP Trap without installing agent on Linux server?

Could we check whether the below MIBs files already included in the existing SCOM server?
- The HOST-RESOURCES_MIB
- Apache web server configuration and status values (APACHE2-MIB).
- disk I/O (UCD-DISKIO-MIB)

include two new monitors in all of the UX based MP's that does monitoring of memory by percentage used. monitors can be disabled by default. monitor A would calculate percentage free (free / total). Monitor B would calculate the same but include cache

It would be nice if we could create baselining monitors on any rule that's generating performance data in Operations Manager. Currently, you can only create baselining monitors for Windows Performance Counters.

Currently admins/users have to look at the Unix/Linux Computers view to see which Resource Pool is monitoring them, and then look at the Resource Pool view, and properties of the resource pool to see its members and the servers responsible for those unix computers.
It'd be great if there were a view that simply showed the management servers in the pool responsible for the unix/linux agent in ONE view. and not have to click in 3 different places to connect the dots.

You have unix/linux log monitoring deployed on a server.
You put the server on maintenance mode for x hours.

<During Maintenance Mode>
During x hours, there are lines that written to the log which would trigger the alert. But alert not triggered since it's in maintenance mode.
</>
<Maintenance Mode Over/>
Log monitoring policy kicks-in. It scans the log file again using the counter BEFORE the maintenance mode. The lines that written during maintenance mode got scanned and triggered an alert. This should not happened.

Current workaround:
- Clean the counter file after maintenance mode over.

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.