locked
Unix/Linux Agents greyed out in SCOM RRS feed

  • 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

    1. 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.

    2. 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.
      
    3. 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.

    4. 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
  • 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


    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 occurred

    And 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-auth

    Also, 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