Unsolved
This post is more than 5 years old
90 Posts
0
4885
OME 2.2: Issue with WSMAN inventory
Hello,
As I stated in a previous thread, we upgraded from a working OME 2.0 to 2.2.
Inventory for Windows servers is running fine (because using snmp/wmi). However, all other OS are not anymore detected correctly (servers are unclassified), relying only on WSMAN. It was working previously (meaning before the upgrade).
Using the Troubleshooting Tool, I can check the communication is OK from the OME server, however OME itself cannot classified any server. I tried to delete some servers and create a new discovery range with no luck. Racadm sslcertview confirms that the certificate is valid. WSMAN discovery has the following setup:
- Secure mode
- skip common name check
- trusted site
Any idea would be welcome.
Thank you
JP
DELL-Vijay B
183 Posts
0
July 13th, 2016 13:00
Hi JP,
Assuming you are discovering the servers via the iDRAC using WS-MAN. In that case, can you check running the following from the OME server's command prompt for the targets which are going unclassified. This might throw some information about what is going wrong.
winrm e cimv2/root/dcim/DCIM_SystemView -u:root -p:calvin -r:10.94.149.171/wsman:443 -SkipCNcheck -SkipCAcheck -encoding:utf-8 -a:basic
Thanks,
Vijay
e-JP
90 Posts
0
July 13th, 2016 14:00
Command will run fine if using the FQDN and will fail if using IP (due to proxy):
winrm e cimv2/root/dcim/DCIM_SystemView -u:root -p:my_pass -r:https://server_fqdn/wsman -SkipCNcheck -SkipCAcheck -encoding:utf-8 -a:basic
DCIM_SystemView
AssetTag
BIOSReleaseDate = 06/03/2015
BIOSVersionString = 1.3.6
blablabla...
winrm e cimv2/root/dcim/DCIM_SystemView -u:root -p:my_pass -r:https://10.136.177.246/wsman -SkipCNcheck -SkipCAcheck -encoding:utf-8 -a:basic
WSManFault
Message = The connection to the specified remote host was refused. Verify that the WS-Management service is running on the remote host and configured to listen for requests on the correct port and HTTP URL.
Error number: -2144108270 0x80338112
The connection to the specified remote host was refused. Verify that the WS-Management service is running on the remote host and configured to listen for requests on the correct port and HTTP URL.
I hope OME is using FQDN for inventory, right?
DELL-Vijay B
183 Posts
0
July 13th, 2016 14:00
This is strange. If the winrm command is successful using 1 host name (fqdn), then ideally the discovery range with the same hostname and wsman settings should be successful.
One last check - hope the system is pingable (ICMP) using the hostname from OME server.
Else, I think it will be good to call support at 800-945-3355 and they will be able to look at your system and provide necessary resolution.
Thanks,
Vijay
e-JP
90 Posts
0
July 13th, 2016 14:00
To answer your question: our discovery ranges use "IP address / range" like "10.136.176-199.*"
To troubleshoot this issue, I have created a discovery range using a few host names (fqdn).
It doesn't work in both cases.
DELL-Vijay B
183 Posts
0
July 13th, 2016 14:00
Hi JP,
OME supports both IP based and FQDN (HostName) based discovery/inventory.
Hope you have defined the discovery range using FQDN only and not IP address in Discovery and Inventory Tab?
Thanks,
Vijay
DELL-Vijay B
183 Posts
0
July 13th, 2016 15:00
Regret that could not help you with your problem.
We did improvement in WSMAN discovery during OME 2.1 by moving to winrm plugin. However, it seems the winrm commands are working fine in your system.
There are lot many new features/improvement in OME 2.2 over OME 2.0. I will suggest to try the Dell support one more time, so that we can help you in resolving your issue.
Thanks,
Vijay
e-JP
90 Posts
0
July 13th, 2016 15:00
Yeah, ping is ok.
Well I think I will revert back to 2.0. We had all kind of trouble with 2.1 and, after spending several days with Dell support, the solution was to roll-back 2.0. I currently don't have time to spent on this.
Something has dramatically changed in WSMAN discovery since 2.0. And not in the good way (at least for us).
Anyway, thank you for your time.
e-JP
90 Posts
0
August 31st, 2016 13:00
A last word on this: after spending a lot of time with Dell support it appears that Microsoft WSMan implementation (used in OME 2.1+) doesn't work well with our proxy. Our only solution right now, is to reinstall OME 2.0 that uses a different WSMan engine (Pegasus) and hope for a possible fix in a later revision.