Asked by:
Unix/Linux Agents greyed out in SCOM

Question
-
Hi,
I had few Linux servers which are greyed out in SCOM with WS management run as account health monitor in critical state. and the below error message in state change events.
The WinRM client cannot process the request. The authentication mechanism requested by the client is not supported by the server or unencrypted traffic is disabled in the service configuration. Verify the unencrypted traffic setting in the service configuration or specify one of the authentication mechanisms supported by the server. To use Kerberos, specify the computer name as the remote destination. Also verify that the client computer and the destination computer are joined to a domain. To use Basic, specify the computer name as the remote destination, specify Basic authentication and provide user name and password. Possible authentication mechanisms reported by server:
I had checked the SCOM account is configured properly on the agent and has sudo permissions. Scxadmin services are also running.
Not sure what is causing this. Any suggestions please.
Regards,
Daya Ram
Monday, August 17, 2015 3:44 PM
All replies
-
Hello,
What Version of Linux We are referring to?
Is this the first Unix Agent or other versions of Agents are already Being Managed in Your SCOM?
Also Have you tried configuring WinRM on the server? If no please have them Configure Using Below Steps.
To configure WinRM with default settings
- Type the following command at a command prompt: Winrm quickconfig.
If you are not running under the local computer Administrator account, you must either select Run as Administrator from the Start menu or use the Runas command at a command prompt.
- When the tool displays Make these changes [y/n]?, type y.
If configuration is successful, the following output is displayed:
WinRM has been updated for remote management. WinRM service type changed to delayed auto start. WinRM service started. Created a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine.
- Keep the default settings for client and server components of WinRM, or customize them. For example, you might need to add certain remote computers to the client configuration TrustedHosts list.
A trusted hosts list should be set up when mutual authentication cannot be established. Kerberos allows mutual authentication, but it cannot be used in workgroups, only domains. A best practice when setting up trusted hosts for a workgroup is to make the list should be as restricted as possible.
- Create an HTTPS listener by typing the following command: winrm quickconfig -transport:https. Be aware that you must open port 5986 for HTTPS transport to work.
Monday, August 17, 2015 4:04 PM - Type the following command at a command prompt: Winrm quickconfig.
-
Hi,
These are RHEL 6 servers.
This is not the first agent I had around 350 linux\unix agents. But the issue is on a specific RHEL 6 agent.
I had checked WinRM service is running on the management server. Is there anything that I need to check on agent side?
Regards,
Daya Ram
Tuesday, August 18, 2015 8:36 AM -
See if you can manually access the agent via winrm running the following command from a command prompt on the SCOM server:
winrm enumerate http://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_Agent?__cimnamespace=root/scx -username:<UNIX/Linux user> -password:<UNIX/Linux password> -r:https://<UNIX/Linux system>:1270/wsman -auth:basic -encoding:utf-8
If this works then try shutting down the SCOM console and restarting it with the clearcache option
"C:\Program Files\Microsoft System Center 2012 R2\Operations Manager\Console\Microsoft.EnterpriseManagement.Monitoring.Console.exe" /clearcache
If the winrm command fails verify the agent is running [scxadmin -status].
Regards,
-Steve
- Edited by Steve Weber [MSFT] Tuesday, August 18, 2015 1:27 PM
Tuesday, August 18, 2015 1:26 PM -
Hi Steve,
WinRM command fails with error:
WSManFault
Message = The server certificate on the destination computer (:
1270) has the following errors:
The SSL certificate could not be checked for revocation. The server used to chec
k for revocation might be unreachable.
The SSL certificate contains a common name (CN) that does not match the hostname
.
Error number: -2147012721 0x80072F8F
A security error occurredAnd Scxadmin service is running on the agent.
omiserver: is running
omiagent: 2 instances running
Please suggest.
Regards,
Daya
Thursday, August 20, 2015 3:59 PM -
Try the same command but add the -skip* options and see if that works.
winrm enumerate http://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_Agent?__cimnamespace=root/scx -username:<UNIX/Linux user> -password:<UNIX/Linux password> -r:https://<UNIX/Linux system>:1270/wsman -auth:basic -skipCACheck -skipCNCheck -skiprevocationcheck -encoding:utf-8
If that works then you have bad certificates on the agents. What does a 'nslookup <agent name>' return when you run it from the SCOM server? Does this match what the certificate has?
On the agent run the following command to get the certificate CN name:
openssl x509 -in /etc/opt/microsoft/scx/ssl/scx.pem -text | grep Subject:
This must match what is in DNS. If it does not than you need to manually generate the certificate and rediscover the agent.
See this link for details.
Regards,
-Steve
Thursday, August 20, 2015 4:48 PM -
Hi Steve,
Command output is:
WSManFault
Message = The WinRM client cannot process the request. The authentication me
chanism requested by the client is not supported by the server or unencrypted tr
affic is disabled in the service configuration. Verify the unencrypted traffic s
etting in the service configuration or specify one of the authentication mechani
sms supported by the server. To use Kerberos, specify the computer name as the
remote destination. Also verify that the client computer and the destination com
puter are joined to a domain. To use Basic, specify the computer name as the rem
ote destination, specify Basic authentication and provide user name and password
. Possible authentication mechanisms reported by server:
Error number: -2147024891 0x80070005
Access is denied.I checked the certificates on the server, it is same as returned by nslookup. Not sure what is wrong with it.
Regards,
Daya
Friday, August 21, 2015 9:27 AM -
Looks like the user you are using to make the winrm call to the agent does not have access to do so. Can this user SSH into the agent?
Is there a /etc/pam.d/omi file and does it contain the following:
#%PAM-1.0
# The configuration of omi is generated by the scx installer.
auth required pam_sepermit.so
auth include password-auth
account required pam_nologin.so
account include password-auth
password include password-auth
session include password-auth-Steve
Friday, August 21, 2015 1:15 PM -
Hi Steve,
yes, the file is there with these configurations.
auth required pam_sepermit.so
auth include password-auth
account required pam_nologin.so
account include password-auth
password include password-auth
session include password-authAlso, I can ssh with the user on the agent.
Monday, August 24, 2015 12:42 PM -
Please look at this link and go through the troubleshooting steps. If they do not help I would suggest you open a support ticket with Microsoft and someone will be able to work with you directly to resolve the issue.
-Steve
Monday, August 24, 2015 2:06 PM -
Hi,
The post is old but i encountred the same issue and resolved it by exporting the scx-certificate of each management server/gateway and import them on each management server/gateway of the linux monitoring pool by the following steps:
open a CMD command prompt in administrator
cd %ProgramFiles%\System Center Operations Manager 2012\Server (or gateway)
scxcertconfig.exe -export filename.cert
copy this file on each server in the pool and run the import command in CMD prompt
scxcertconfig.exe -import filename.cert
hope that could help someone
Thursday, May 28, 2020 3:59 PM