Unsolved
This post is more than 5 years old
2 Intern
•
615 Posts
0
55857
June 3rd, 2014 12:00
Servers in OEM Devices
What would cause some servers that have always shown correctly in device listing in a custom device group are suddenly listing in OEM Devices?
They have the same chassis type and DRAC firmware version and discovery protocol as servers that are listing correctly.
Sometimes I think OME is possessed as it does some really wacky things sometimes.
OME Version:
1.3.0.1533
No Events found!


DELL-Pupul M
2 Intern
•
1K Posts
0
June 3rd, 2014 23:00
Hi Cameron,
There is a similar post which may be of some help for you. Let us know if it helps you in any way.
http://en.community.dell.com/techcenter/systems-management/f/4494/p/19582496/20638998.aspx#20638998
cameronredux
2 Intern
•
615 Posts
0
June 4th, 2014 09:00
Thanks. Not able to mess around unplugging and plugging back in production servers but thanks.
1badger11
14 Posts
0
June 4th, 2014 11:00
I would have to agree, I like having OME rather than not but it is not yet stable or consistent regarding classifications. I have a few items showing up under OEM that just the day before were showing up under either ESXi or RAC devices and even have a guest of one of the hosts showing under OEM. I also have a Exchange server now showing under OEM that was previously showing under Servers only. I really am more concerned with getting the alerts and thus far that seems to still work fine no matter what classification OME says.
DELL-Rob C
4 Apprentice
•
2.8K Posts
0
June 4th, 2014 12:00
Hey cameron...
Is there anything unusual about the MAC address on that box? Can you look at the Mac in the database and see if there is anything suspect about it?
Thx
Rob
cameronredux
2 Intern
•
615 Posts
0
June 4th, 2014 15:00
Hi Rob,
I have 5 servers listing incorrctly in OEM right now.
All MAC addresses look normal. Here is one:
00:26:b9:5d:1c:ca
The MAC addresses listed the MAC addresses of the DRAC NIC.
All devices are discovered via DRAC using WS-Man Protocol.
Same as all our other servers that are fine.
I have tried updating DRACs from 1.96 to 1.97 and rediscovering. Same issue.
I have tried deleting the devices from OME and rediscovering. Same issue.
As mentioned these use to not list in OEM devices and listed all data correctly. They are currently listing limited data as though they were being discovered using a different protocol like IPMI or SNMP but I only discover servers with WS-Man and my discovery ranges are contiguous for each protocol. I don't mix and match :)
IE
Servers are in one contiguous range for only WS-Man discovery.
SANs are in another contiguous range for only Dell/EMC Array discovery.
We don't have any OMSA.
DELL-Pupul M
2 Intern
•
1K Posts
0
June 4th, 2014 23:00
Hi Cameron,
Can you try increasing the timeout and retries during WSMAN discovery and inventory and see if that helps?
DELL-Rob C
4 Apprentice
•
2.8K Posts
0
June 5th, 2014 08:00
Thanks cameron and others on the thread.
Yeah, play with the timeout value as suggested. I'll send this data along to the team for review. Not sure what is up here, we did not see this, but a few of you guys are running into it. So we need to see if it is unique to a iDrac version or what. Basically, if we can't get the model number from the iDrac or OMSA it gets moved to OEM.... Maybe we need to put a setting on OME to disable this OEM classification for folks that don't need it. Let me dig more.
Thanks,
Rob
cameronredux
2 Intern
•
615 Posts
0
June 5th, 2014 10:00
Thanks Guys,
My WS-Man timeout was already at 15 seconds. I have moved this to 30 seconds and am rediscovering.
Retries was 4. It's still at 4.
Discovery, inventory and status have all been gradually moved to their slowest setting to try to trouble shoot this and other connectivity issues with OME.
This is on a dedicated 8 core 16GB RAM Dell R410 chassis and all DRAC and this server are on their own segregated physical network and are the only traffic on this network with only about 250 devices being discovered.
Ping from the OME chassis to one of the devices the end up in OEM section:
C:\Users\Administrator>ping 10.102.24.244
Pinging 10.102.24.244 with 32 bytes of data:
Reply from 10.102.24.244: bytes=32 time<1ms TTL=64
Reply from 10.102.24.244: bytes=32 time<1ms TTL=64
Reply from 10.102.24.244: bytes=32 time<1ms TTL=64
Reply from 10.102.24.244: bytes=32 time<1ms TTL=64
Ping statistics for 10.102.24.244:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms
When using the WS-Man test in the troubleshooting tool the time from click to return of data to this same device is 1 minute 2 seconds but returns a connected status:
Protocols Selected are:
WSMAN
Connected.
profiles found on the remote device are:
1. OS Deployment
2. Software Inventory
3. Software Update
4. Job Control
5. LC Management
6. Persistent Storage
7. Simple NIC
8. Simple FC
9. BIOS and Boot Management
10. Simple RAID
11. Fan
12. Power Supply
13. iDRAC Card
14. Memory
15. CPU
16. System Info
17. PCI Device
18. Video
19. Base Server
20. Service Processor
21. SM CLP Admin Domain
22. Power State Management
23. Active Directory Client
24. Simple Identity Management
25. Role Based Authorization
26. Record Log
27. DHCP Client
28. DNS Client
29. Ethernet Port
30. Ethernet Port
31. IP Interface
32. Power Supply
33. Command Line Protocol Service
34. Physical Asset
35. Base Metrics
36. Virtual Media
37. USB Redirection
38. Power Utilization
39. SMASH Collections
Another server with the same DRAC version that is returning all data correctly and is not in OEM devices has the same PING times and same troubleshooting tool ws-man test return times.