Start a Conversation

Unsolved

This post is more than 5 years old

3099

August 14th, 2017 08:00

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?

14 Posts

August 15th, 2017 07:00

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

August 15th, 2017 07:00

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

August 15th, 2017 22:00

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

14 Posts

August 31st, 2017 08:00

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.

August 31st, 2017 08:00

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

No Events found!

Top