Start a Conversation

Unsolved

This post is more than 5 years old

DV

23388

October 27th, 2016 06:00

Resolution for the issue - iDRAC or CMC displays an “unknown” status after upgrading to the latest firmware version

Hi OME users,

It has been observed that after upgrading to the latest firmware version (iDRAC >= 2.40.40.40, M1000e CMC >= 5.2, FX2 CMC >= 1.4, VRTX CMC >= 2.2), the iDRAC or CMC displays an “unknown” status.

The latest firmware version supports TLS 1.1 as the default communication protocol. If the browser or operating system where OpenManage Essentials is installed, does not support TLS 1.1 protocol, then the device displays an “unknown” status.

To resolve this issue, see “Step 2: Verifying Dell Management Consoles” in the following KB article: http://www.dell.com/Support/Article/us/en/19/SLN302365

 Note: Ensure the required registry updates are done either manually or using the “Easy Fix” described in the Microsoft support article - "Update to enable TLS 1.1 and TLS 1.2 as a default secure protocols in WinHTTP in Windows"

Thanks,
Vijay

5 Posts

November 2nd, 2016 15:00

I'm still having this issue after trying your fix above with IDRACs showing unknown and also the servers with 2.40.40.40 not updating the inventory properly. All of them are showing non-compliant though their IDRACs are up to date. My OME server is a Windows server 2012 R2 version 2.2.0.2056. Any help would be appreciated.

16 Posts

November 10th, 2016 11:00

Same issue here, I've followed the original steps with no success.. All applicable iDRACs are updated but OME still shows them as non-compliant. OME version 2.2.0.2056. Any direction on how to fix this?

16 Posts

November 11th, 2016 07:00

This is what I get running the WS-Man test:

Using TLS 1.0 for SSL/TLS handshake.
Error: A complete request could not be sent to the remote server.
Using TLS 1.1 for SSL/TLS handshake.
UntrustedRoot: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.

TLS 1.1 Handshake successful.

The WS-Man target has TLS 1.1 enabled. If OME is unable to discover this device, install the required updates on the system where OME is installed. For more details, see “Enabling support for TLS 1.1 or 1.2” at delltechcenter.com/ome.


Identify Failed. Could not connect

Let me know if I can give you any additional information on this.

November 11th, 2016 07:00

Hi,

Windows Server 2012 R2 has by default TLS 1.1/1.2 enabled and you shall not be hitting the issue with OME installed on Windows Server 2012R2.

Can you run the latest Troubleshooting tool shipped with OME 2.2 and perform ws-man test?

That will give you some direction.

Thanks,
Vijay

615 Posts

November 11th, 2016 09:00

I am seeing similar issues with new servers running 2.40.40.40 for DRAC firmware:

Protocols Selected are: WSMAN

Using TLS 1.0 for SSL/TLS handshake.
Error: A complete request could not be sent to the remote server.
Using TLS 1.1 for SSL/TLS handshake.
TLS 1.1 Handshake successful.

The WS-Man target has TLS 1.1 enabled. If OME is unable to discover this device, install the required updates on the system where OME is installed. For more details, see “Enabling support for TLS 1.1 or 1.2” at delltechcenter.com/ome.

Connected.
WSMAN profiles found on the remote device are:
1. Profile Registration
2. Base Metrics
3. Base Server and Physical Asset
4. BIOS and Boot Management
5. CPU
6. Event Filter
7. Fan
8. Fiber Channel
9. iDRAC Card
10. Job Control
11. LC Management
12. License Management
13. Memory
14. OS Deployment
15. PCI Device
16. Persistent Storage
17. Power State Management
18. Power Supply
19. Record Log
20. Role Based Authorization
21. Sensors
22. Service Processor
23. Simple Identity Management
24. Simple NIC
25. Simple RAID
26. Software Inventory
27. Software Update
28. System Info
29. Video
30. SystemQuickSync
31. USBDevice
32. Physical Computer System View
33. Command Line Protocol Service
34. SM CLP Admin Domain
35. SMASH Collections

November 11th, 2016 14:00

Thanks Cameron for the details.

As a next step, can you try running the below winrm commands replacing IP/credentials as required and see if it returns valid output.

winrm e cimv2/root/dcim/DCIM_SystemView -u:user -p:password -r:https://a.b.c.d/wsman:443 -SkipCNcheck -SkipCAcheck -encoding:utf-8 -a:basic 

If it gives valid output, then OME should not have any problem discovering the respective iDRAC.

If it does not, then I would suggest to refer "How the DefaultSecureProtocols registry entry works"  in https://support.microsoft.com/en-us/kb/3140245 and ensure required registries are enabled.

Regards
Vijay

615 Posts

November 11th, 2016 15:00

Thanks Vijay,

I had previously installed the windows update from that link but I did not run the "easy fix" . After running that and rebooting OME server I am now able to fully see my dracs with 2.40.40.40 in OME.

Thanks for your help!

November 13th, 2016 21:00

Glad that your problem got solved.

Thanks for taking time and updating this thread.

Regards
Vijay

9 Posts

April 12th, 2017 06:00

Hi we have some similar issues with ESXi hosts and updating to latest firmware.

We have discovered ESXi hosts by WSMAN and iDRAC and the Servers all reported under RAC and ESXi groups in OME all ok.

So we set about updating the firmware using OME - packages all downloaded ok and started to update.

However the task does not complete successfully - runs firmware updates but never reports back and times out.  We have checked and in fact the firmware did update on the hosts we chose - iDRAC, BIOS, LifeCycle, OS Driver and UEFI Diags - so the iDRAC shows versions are updated.

However the inventory despite being updated shows previous versions of the firmware in OME.  Also RAC in OME reports as off and we can no longer access the iDRAC via IE - 'this page cannot be displayed' yet before the updates we could access via IE.  Now have to use Firefox and add exception to access the iDRAC.

We experienced the same issue when updating another host using OME - so it seems the update of the iDRAC means it can no longer communicate back to OME.

Servers R720 and R730 ESXi, OME on Server 2012

26 Posts

July 19th, 2017 07:00

Hi,

we have the same problem with new installation OpenManageEssentials_2_3_A00 on W2012R2. I can see R630 (ESXi 6.0U3 with OMSA 8.5.0-2372) or R320 (ESXi 6.5 with OMSA 8.5.0-2372) from OME server:

PS C:\Windows\system32> winrm e cimv2/root/dcim/DCIM_SystemView -u:xxxxxx -p:xxxxxx -r:https://x.x.x.x/wsman:443 -SkipCNcheck -SkipCAcheck -encoding:utf-8 -a:basic
DCIM_SystemView
AssetTag
BIOSReleaseDate = 01/17/2017
BIOSVersionString = 2.4.3
BaseBoardChassisSlot = NA
BatteryRollupStatus = 1
BladeGeometry = 255
BoardPartNumber = 0CNCJWA05
BoardSerialNumber = CN7475151Q1047
CMCIP = null
CPLDVersion = 1.0.1
CPURollupStatus = 1
ChassisModel
ChassisName = Main System Chassis
ChassisServiceTag =  
ChassisSystemHeight = 1
CurrentRollupStatus = 1
DeviceDescription = System
EstimatedExhaustTemperature = 42
EstimatedSystemAirflow = 18


FQDD = System.Embedded.1
FanRollupStatus = 1
HostName = stratus.racom.cz
IDSDMRollupStatus = 1
InstanceID = System.Embedded.1
IntrusionRollupStatus = 1
LastSystemInventoryTime = 20170704181715.000000+000
LastUpdateTime = 20170704181502.000000+000
LicensingRollupStatus = 1
LifecycleControllerVersion = 2.41.40.40
Manufacturer = Dell Inc.
MaxCPUSockets = 2
MaxDIMMSlots = 24
MaxPCIeSlots = 3
MemoryOperationMode = OptimizerMode
MemoryRollupStatus = 1
Model = PowerEdge R630
NodeID = 
PSRollupStatus = 1
PlatformGUID = 32345a4f-c0b5-4480-4710-005a4c4c4544
PopulatedCPUSockets = 2
PopulatedDIMMSlots = 12
PopulatedPCIeSlots = 2
PowerCap = 481
PowerCapEnabledState = 3
PowerState = 2
PrimaryStatus = 1
RollupStatus = 1
SDCardRollupStatus = 1
ServerAllocation = null

StorageRollupStatus = 1
SysMemErrorMethodology = 6
SysMemFailOverState = NotInUse
SysMemLocation = 3
SysMemMaxCapacitySize = 3145728
SysMemPrimaryStatus = 1
SysMemTotalSize = 196608
SystemGeneration = 13G Monolithic
SystemID = 1537
SystemRevision = 0
TempRollupStatus = 1
TempStatisticsRollupStatus = 1
UUID = 4c4c4544-005a-4710-8044-b5c04f5a3432
VoltRollupStatus = 1
smbiosGUID = 44454c4c-5a00-1047-8044-b5c04f5a3432

If I run WSMAN test in Troubleshooting Tool with both Skip CA & CN Check enabled I get full info:

Using TLS 1.0 for SSL/TLS handshake.
Error: A complete request could not be sent to the remote server.
Using TLS 1.1 for SSL/TLS handshake.
TLS 1.1 Handshake successful.

The WS-Man target has TLS 1.1 enabled. If OME is unable to discover this device, install the required updates on the system where OME is installed. For more details, see “Enabling support for TLS 1.1 or 1.2” at delltechcenter.com/ome.

Connected.
WSMAN profiles found on the remote device are:
1. Profile Registration
2. Base Metrics
3. Base Server and Physical Asset
4. BIOS and Boot Management
5. CPU
6. Event Filter
7. Fan
8. Fiber Channel
9. iDRAC Card
10. Job Control
11. LC Management
12. License Management
13. Memory
14. OS Deployment
15. PCI Device
16. Persistent Storage
17. Power State Management
18. Power Supply
19. Record Log
20. Role Based Authorization
21. Sensors
22. Service Processor
23. Simple Identity Management
24. Simple NIC
25. Simple RAID
26. Software Inventory
27. Software Update
28. System Info
29. Video
30. SystemQuickSync
31. USBDevice
32. Physical Computer System View
33. Command Line Protocol Service
34. SM CLP Admin Domain
35. SMASH Collections

Otherwise I get an error:

Using TLS 1.0 for SSL/TLS handshake.
Error: A complete request could not be sent to the remote server.
Using TLS 1.1 for SSL/TLS handshake.
RemoteCertificateNameMismatch
UntrustedRoot: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.

TLS 1.1 Handshake successful.

The WS-Man target has TLS 1.1 enabled. If OME is unable to discover this device, install the required updates on the system where OME is installed. For more details, see “Enabling support for TLS 1.1 or 1.2” at delltechcenter.com/ome.


Identify Failed. Could not connect

Is it certificate problem? Both servers are discovered, inventoried and statused in OME but stay unknown and Device Type Unclassified with Device Summary and NIC Information only.

July 20th, 2017 07:00

Hi Lavicky,

What`s the discovery type used for discovering these devices in OME? Basically, second page in discovery wizard where device type filtering is done. 

1) If iDRAC`s were discovered using other than below highlighted Device Type in OMEv2.x, then due to OMEv2.3`s default behavior of “Device Type based discovery”, post upgrade & re-discovery those iDRAC devices will be unclassified/unknown. Hence the status changes from previous state to unknown.

I would request you to check the filter settings on your discovery ranges and ensure they match the type of devices available on them.

2) Another way would be to ignore this setting globally for all your discovery and keep the behavior same as of OME 2.x < OME 2.3. Navigate to Settings -> Discovery Settings and un-check "Discover the selected Device Types only" checkbox.

Let us know if this is helpful.

26 Posts

July 20th, 2017 09:00

Hi Shivendra,

it's my mistake. I've used ESXi Host + Guest device type for discovering devices but iDRAC IP and credentials. After changing to ESXi IP and credentials it looks like working well.

Thanks for your support.

Tomas

July 20th, 2017 10:00

Hi Tomas,

Glad that it worked out.

61 Posts

November 9th, 2017 05:00

Deleted, this was a firewall issue.

No Events found!

Top