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 220.127.116.11
I have also tried with iDRAC8 fw 18.104.22.168. 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?
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 = falseAuth Basic = true Digest = true Kerberos = true Negotiate = true Certificate = true CredSSP = falseDefaultPorts HTTP = 5985 HTTPS = 5986TrustedHosts
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.
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.