Resolution for the issue - iDRAC or CMC displays an “unknown” status after upgrading to the latest firmware version - Dell OpenManage Essentials - Systems Management - Dell Community
Systems Management Forums

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

Systems Management

Systems Management
Dell Systems Management Solutions: Dell OpenManage, iDRAC, Repository Manager, Microsoft SCCM, Chassis Managment Controller, and more

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

  • 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.

  • 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?

  • 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

  • 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 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

  • 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

  • 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!

  • Glad that your problem got solved.

    Thanks for taking time and updating this thread.

    Regards
    Vijay

  • 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

  • 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 =  <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 = 2.41.40.40
    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:

    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.

  • 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.

    Thanks,

    Shivendra

  • 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

  • Hi Tomas,

    Glad that it worked out.

    Thanks,

    Shivendra