OME 2.3, Server 2016 not gathering iDRAC/WS-Man inventory - Dell OpenManage Essentials - Systems Management - Dell Community
Systems Management Forums

OME 2.3, Server 2016 not gathering iDRAC/WS-Man inventory

Systems Management

Systems Management
Dell Systems Management Solutions: Dell OpenManage, iDRAC, Repository Manager, Microsoft SCCM, Chassis Managment Controller, and more

OME 2.3, Server 2016 not gathering iDRAC/WS-Man inventory

  • I previously built OME 2.3 on Server 2012 R2 to test the solution would work for us. It did so I have moved it on to Server 2016. I'm having a considerable issue. I dont seem to be able to pull anything from an iDRAC7 and iDRAC8 I'm testing with. Now i am troubleshooting I am getting inconsistent results from the Server 2012R2 install. 

    The main issue:

    I have setup a user account with "login" and "logs" privileges in iDRAC. I create a discovery on OME (2012R2) for only WS-Man, for only that iDRAC and discover. Result: it discovers and I get full inventory. 

    I create a discovery on OME (2016) for the same iDRAC and again for the same account as before and run discovery. I only get the iDRAC to appear in "Unknown" with no inventory. 

    I run the torubleshooting tool on both and I get the results that show it working and connecting on both. 

    The above example was iDRAC7 fw 2.21.21.21

    I have also tried with iDRAC8 fw 2.43.43.43. This is a little different. Using an account with "login" and "logs" privileges in iDRAC. Again setting up a discovery on both OME installations, neither are able to gather inventory. Using the troubleshooting tool the 2012 R2 server is able to handshake with TLS 1.1, connects to WS-Man but fails to gather the profiles. In the troubleshooting tool on 2016 it is able to handshake with TLS 1.1, connects to WS-Man and does gather the profiles. 

    Continuing from the above example, I delete the devices and the discovery. I recreate the discovery changing the discovery rule to run as an account with administrator privileges and run the discovery. The OME on 2016 fails to gather inventory. OME on 2012 R2 gathers the inventory. 

    I delete the devices and the discovery. I recreate the discovery but revert to using the restricted account with only "login" and "logs" and try the discovery again. OME on 2016 fails to gather inventory. OME on 2012 R2 successfully gathers inventory and when I try the troubleshooting tool it connects using TLS 1.1 and gathers the WS-Man profiles. 

    I have also been using this command on both 2012 R2 and 2016. I had to make a small change in 2016 to allow basic auth. The result of the command is always successful. 

    winrm e cimv2/root/dcim/DCIM_SystemView -u:sername -p:assword -r:https://192.168.1.55/wsman:443 -SkipCNcheck -SkipCAcheck -encoding:utf-8 -a:basic

    OME 2.3 on Server 2016 is consistently unable to gather inventory. This is what i want to fix. Can someone help?

  • Hi,

    Thanks for the query.

    As you mentioned the same server discovers fine with OME 2.3 on WS 2012 R2, also, the TT test passes on both OSes, the problem could be with WinRM client (OME uses for WSMAN protocol) configuration on WS 2016. I see that you have already enabled basic auth, please ensure below configuration is met:

    >winrm get winrm/config/client

    Client
        NetworkDelayms = 5000
        URLPrefix = wsman
        AllowUnencrypted = false
    Auth
         Basic = true
         Digest = true
         Kerberos = true
         Negotiate = true
         Certificate = true
         CredSSP = false
    DefaultPorts
         HTTP = 5985
         HTTPS = 5986
    TrustedHosts

    Thanks,

    Shivendra

  • Hi Shivendra, thanks for the reply, here is the output:

    Client
    NetworkDelayms = 5000
    URLPrefix = wsman
    AllowUnencrypted = true
    Auth
    Basic = true
    Digest = true
    Kerberos = true
    Negotiate = true
    Certificate = true
    CredSSP = false
    DefaultPorts
    HTTP = 5985
    HTTPS = 5986
    TrustedHosts

  • Settings look good. Give a restart to the server and try discovery. This action will restart all necessary services and should resolve the problem.

    Thanks,

    Shivendra

  • Hi, sorry for the delay in responding.

    After digging through many things I noticed that my colleague had built the server and used netsh to define a proxy while not defining any bypass settings.

    The connections were therefore trying to route through our proxy server which was causing the problems (and also explains why it was ok on the other server).

    I disabled the proxy setting and the connections are working fine now. I don't know why the tests succeeded but this did seem to be the issue.

  • Good to know your problem is resolved. Troubleshooting tool might work as it does not use winrm.

    Thanks,

    Shivendra