The times I have seen that error message either the sudo permissions are not 
correct or the discovery process from the server is being run with su (which 
the account likely won’t have) instead of sudo elevation. For configuring sudo 
permissions, the link that was sent earlier is the lowest common denominator 
for agents to be installed and running on a system:

                
http://social.technet.microsoft.com/wiki/contents/articles/7375.configuring-sudo-elevation-for-unix-and-linux-monitoring-with-system-center-2012-operations-manager.aspx

I double checked and the sudoers.d lines match for Linux/Unix agents I have in 
production (OM2012R2 UR3).


Towards the second question, the Linux/Unix MPs and agents aren’t written to 
proxy for others systems. The agents need to be on all the servers… Unless you 
write custom management packs to do that proxying, in which case authoring SCOM 
management packs for Linux/Unix is a whole different ball game. ☺


-Jeffrey

=============================================
Jeffrey Miller
Senior Systems Administrator
The University of Iowa
ITS – Enterprise Infrastructure
16 Lindquist Center South
Iowa City, IA 52242-1727
(319) 384-3655
=============================================

From: [email protected] [mailto:[email protected]] On 
Behalf Of Cooper, Karen A.
Sent: Wednesday, September 24, 2014 1:12 PM
To: [email protected]
Cc: Cooper, Karen A.
Subject: [msmom] RE: Monitor Linux servers without SCOM 2012 agents (agentless)?

Kevin,
Thank you for the information. We have a couple of additional issues/questions.

·         Issues:

o   After SCOM discovered the Red Hat Linux server, it appears to have tried to 
copy the agent to the required directory on the Linux server but it didn’t 
install the agent (it also deleted the newly create directory)

§  Ran the commands from the documentation so the SUDO account has all correct 
permissions

§  Troubleshooting – search web but couldn’t find any fix.

·         All I found was that “this is a permission issue” we ran the command 
for the SUDO account

·         Error from SCOM Console:
[cid:[email protected]]



·         Questions:

o   What is the lowest permissions that the SUDO account can have to discovery 
and monitor a Linux server?

o   Our Linux group doesn’t want an agent installed on all of their Linux 
servers. I was thinking if we can install the SCOM agent on one Linux server 
then have that act as the SCOM proxy and then we wouldn’t have to install the 
agent on any other Linux servers – would that work?


Thanks

Karen

From: [email protected]<mailto:[email protected]> 
[mailto:[email protected]] On Behalf Of Kevin Holman
Sent: Wednesday, September 17, 2014 2:23 PM
To: [email protected]<mailto:[email protected]>
Subject: [msmom] RE: Monitor Linux servers without SCOM 2012 agents (agentless)?

http://blogs.technet.com/b/kevinholman/archive/2012/03/18/deploying-unix-linux-agents-using-opsmgr-2012.aspx

http://support.microsoft.com/kb/2993901

http://social.technet.microsoft.com/wiki/contents/articles/4966.troubleshooting-unixlinux-agent-discovery-in-system-center-2012-operations-manager.aspx

http://social.technet.microsoft.com/wiki/contents/articles/7375.configuring-sudo-elevation-for-unix-and-linux-monitoring-with-system-center-2012-operations-manager.aspx



From: [email protected]<mailto:[email protected]> 
[mailto:[email protected]] On Behalf Of Cooper, Karen A.
Sent: Wednesday, September 17, 2014 11:15 AM
To: [email protected]<mailto:[email protected]>
Subject: [msmom] RE: Monitor Linux servers without SCOM 2012 agents (agentless)?

Thank you for the quick response.
So there really isn’t an agent installed on the Linux servers? How does the 
OMIServer get installed on the Linux servers. I have configured the RunAs 
accounts and Profiles. Now I am going to work with the Linux admin to get the 
SUDO working. Once that is done is that when SCOM installs the OMIserver on the 
Linux servers?
Is there a link that explains this in more detail?

Thanks

Karen

From: [email protected]<mailto:[email protected]> 
[mailto:[email protected]] On Behalf Of Subramani 
Ananthapadmanabhan
Sent: Wednesday, September 17, 2014 1:20 PM
To: [email protected]<mailto:[email protected]>
Subject: [msmom] RE: Monitor Linux servers without SCOM 2012 agents (agentless)?

Even today there is no SCOM agent on the Linux/Unix box. Hence it is agentless 
in the sense that there is no healthservice on the Linux machine nor are there 
any workflows running on the Linux box.

What we install on the Linux Machine is something like winrm/WMI (OMIServer) 
that the Management server queries to get info about the Linux machine.

SCOM was always agentless when it came to monitoring Linux.

Thanks and Regards
Mani

From: [email protected]<mailto:[email protected]> 
[mailto:[email protected]] On Behalf Of Sven Wells
Sent: Wednesday, September 17, 2014 12:11 PM
To: [email protected]<mailto:[email protected]>
Subject: [msmom] RE: Monitor Linux servers without SCOM 2012 agents (agentless)?

I would be interested in that as well.

Thanks,
Sven

From: [email protected]<mailto:[email protected]> 
[mailto:[email protected]] On Behalf Of Cooper, Karen A.
Sent: Wednesday, September 17, 2014 12:19 PM
To: [email protected]<mailto:[email protected]>
Cc: Cooper, Karen A.
Subject: [msmom] Monitor Linux servers without SCOM 2012 agents (agentless)?

Hi,
I have heard some rumors that Linux servers could be monitored by SCOM 2012 
without installing an agent (agentless). Is this true? If so could I please be 
provided a link to the instructions on how to do this?

Thanks
Karen




This email transmission and any documents, files or previous email messages 
attached to it may contain information that is confidential or legally 
privileged.
If you are not the intended recipient or a person responsible for delivering 
this transmission to the intended recipient, you are hereby notified
that you must not read this transmission and that any disclosure, copying, 
printing, distribution or use of this transmission is strictly prohibited.
If you have received this transmission in error, please immediately notify the 
sender by telephone or return email and delete the original transmission and 
its attachments without reading or saving in any manner.






Reply via email to