I am trying to install SCOM agent 1.5.1-256.universal.1.x64.deb for an Ubuntu Server and when the wizard is completing the installation I received the message below .
Unsupported OpenSSL version - must be either 0.9.8* or 1.0.*.
I am using the version OpenSSL 1.1.0 out of supported range.18 votes
At the moment we need to allow /tmp/scx* scripts to be elevated via sudoers. This is a huge security conflict.13 votes
Mounted disks are not discovered, you should have an option to do this9 votes
Make us be able to use wildcards in the log file path of the "UNIX/Linux Log File Monitoring"-template.9 votes
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.5 votes
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.
- Clean the counter file after maintenance mode over.3 votes
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.2 votes
The introduced functions for monitoring MySQL is a great step in the right direction, but to be of any real value in the business this functionality needs to be extended with support for Monitoring MySQL Clusters.
The Pack should discover if the node is configured as a cluster member, identify the remaining partners, and adopt monitoring to expose cluster related health details.1 vote
Please see forum thread here:
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.1 vote
Unix/Linux monitoring is too limited. Need advanced monitoring Rules/Monitors.1 vote
- Don't see your idea?