SCEP 2012 System Center Monitoring Pack for Linux v4.5.10.1 Problem

Question

Hi Everyone!
We are having a problem with OpsMgr 2012 R2 and the System Center Monitoring Pack for SCEP 2012 for Linux v4.5.10.1.  We have successfully deployed the Linux OpsMgr 2012 R2 agent to our test CentOS 6.5 VM as well as SCEP 2012 v4.5.10.1.  We have
imported the System Center Monitoring Pack for SCEP 2012 for Linux management packs into OpsMgr 2012 R2 which is successfully discovering SCEP on our Linux VM, but when looking at the details for the monitor, it indicates that SCEP is "not found"
as seen in the following screen shot...
As seen in the following screen shots, everything else seems to be installed, configured, and working properly...
Any assistance or guidance would be greatly appreciated!
Regards,
JJ

Answer 1

Magnus_001 (big ups) and I were able to get discovery to stop failing on the Linux side of things, but the SCOM MP is still highly problematic.  Their pdf guides for SCEP implementation on Linux has a bunch of typos and errors -- for example, listing
'/bin/sh' instead of '/bin/bash', and one of the lines (the one that includes "export LANG=C" won't run no matter what.  When we disassembled the SCOM MP, we found that there's an extraneous space at the end of the command, current thought is
that that's causing a regex to fail within sudo.  All of their commands, from what I can tell, need to be specified as NOPASSWD within sudo; if you see errors about ssh-askpass with that you can confirm that there are likely typos in their guide sourced
from the pdf.  We eventually allowed '/bin/bash' to get the programs to run since we couldn't get a regex match to catch their command (which should be in a script).  We are out of failures that we can discover with logging on the Linux side; it's
likely to be an error within the MP at this point.
When we look at the powershell script in the MP library, the "not found" error is the default state, set immediately after stdout is captured from the discovery script.  I'm guessing that there's some problem interaction between that script
and the parsing thereof, as when we run the script locally as root we see the output that we'd expect. For all I know that's a line ending or locale problem.
Troubleshooting on the linux end is problematic, as instead of distributing a script to check on the linux side (which makes the sudo part of things much easier), the script is hard-coded within the MP.  From what I understand it would need to be disassembled
and recompiled to change.
The snippet below may be of use to someone for use in their sudoers file, it will make the checks work on the linux side at least.  I wouldn't recommend this for anything beyond testing, as specifying that an account can run a full bash shell as root
without a password is a terrible idea.
#replace scomactionaccount with whatever your scom action account is called
User_Alias SCOM = scomactionaccount
Runas_Alias SCOM = root
SCOM ALL = (SCOM) NOPASSWD: /opt/microsoft/scx/bin/scxlogfilereader -p
SCOM ALL = (SCOM) NOPASSWD: /bin/bash