Hi OME users,
It has been observed that after upgrading to the latest firmware version (iDRAC >= 184.108.40.206, 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"
I'm still having this issue after trying your fix above with IDRACs showing unknown and also the servers with 220.127.116.11 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 18.104.22.1686. Any help would be appreciated.
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 22.214.171.1246. Any direction on how to fix this?
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.
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.
I am seeing similar issues with new servers running 126.96.36.199 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 Registration2. Base Metrics3. Base Server and Physical Asset4. BIOS and Boot Management5. CPU6. Event Filter7. Fan8. Fiber Channel9. iDRAC Card10. Job Control11. LC Management12. License Management13. Memory14. OS Deployment15. PCI Device16. Persistent Storage17. Power State Management18. Power Supply19. Record Log20. Role Based Authorization21. Sensors22. Service Processor23. Simple Identity Management24. Simple NIC25. Simple RAID26. Software Inventory27. Software Update28. System Info29. Video30. SystemQuickSync31. USBDevice32. Physical Computer System View33. Command Line Protocol Service34. SM CLP Admin Domain35. SMASH Collections
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.
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 188.8.131.52 in OME.
Thanks for your help!
Glad that your problem got solved.
Thanks for taking time and updating this thread.
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
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:basicDCIM_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 = <Service tag removed> ChassisSystemHeight = 1 CurrentRollupStatus = 1 DeviceDescription = System EstimatedExhaustTemperature = 42 EstimatedSystemAirflow = 18
<Express service code removed>
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 = 184.108.40.206 Manufacturer = Dell Inc. MaxCPUSockets = 2 MaxDIMMSlots = 24 MaxPCIeSlots = 3 MemoryOperationMode = OptimizerMode MemoryRollupStatus = 1 Model = PowerEdge R630 NodeID = <Service tag removed> 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
<Service tag removed>
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:
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.RemoteCertificateNameMismatchUntrustedRoot: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.
TLS 1.1 Handshake successful.
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.
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.
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.
Glad that it worked out.