Unsolved

This post is more than 5 years old

2 Intern

 • 

615 Posts

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

2 Intern

 • 

1K Posts

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

2 Intern

 • 

615 Posts

June 4th, 2014 09:00

Thanks. Not able to mess around unplugging and plugging back in production servers but thanks.

14 Posts

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.

4 Apprentice

 • 

2.8K Posts

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

2 Intern

 • 

615 Posts

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.

2 Intern

 • 

1K Posts

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?

4 Apprentice

 • 

2.8K Posts

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

2 Intern

 • 

615 Posts

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.

No Events found!

Top