Skip to main content
  • Place orders quickly and easily
  • View orders and track your shipping status
  • Enjoy members-only rewards and discounts
  • Create and access a list of your products
  • Manage your Dell EMC sites, products, and product-level contacts using Company Administration.

Dell OpenManage Integration with Microsoft Windows Admin Center Version 3.0 User’s Guide

Troubleshooting and Frequently asked questions

Upgrading

Extension installation failed

When you try to install OpenManage Integration snap-in during Azure Stack HCI cluster creation or update, the extension installation may fail.

Reason: An older version of the extension (OMIMSWAC 1.1.1 or earlier) may have already been installed.

Resolution:
  • Uninstall the older version, and then install the OpenManage Integration snap-in during Azure Stack HCI cluster creation or update. See Installing Dell OpenManage Integration with Microsoft Windows Admin Center.
  • To upgrade to OpenManage Integration snap-in from earlier versions, go to Extensions > Installed extensions tab. Select Dell OpenManage Integration extension with the status "Update available (version)," and then click Update.

Why am I not able to install the extension using the local feed?

The installation of the extension using the local feed may fail with the below error:
Couldn't install the extension: 'Dell OpenManage Integration'. Error: Extension dell-emc.openmanage-integration <Version> was not available from any extension feed.

Ensure that the file name is dell-emc.openmanage-integration.<Version>.nupkg while adding the OMIMSWAC extension. The installation fails if the default file name is changed.

Why am I not able to install the extension?

The installation of the extension may fail with the below error:

Couldn't install the extension: 'Dell
OpenManage Integration'. Error: Extension
dell-emc.openmanage-integration <Version> was not available
from any extension feed.

Before installing the extension, ensure the followings:

  • The extension is installed on a supported WAC version. For information about supported WAC version, see the Compatibility Matrix.
  • The CredSSP is disabled.

For more information about installing extension prerequisites, see Installing Dell OpenManage Integration with Microsoft Windows Admin Center.

Licensing

Licensing status is Unknown or Non-licensed

If the license status is Unknown or Non-licensed, ensure that:
  • License is not expired.
  • Licenses are present on each target node.
  • Target node is powered on and not in the reboot state. Also, no reboots are pending for the target node.
  • Redfish is enabled.
  • Azure stack HCI license or PowerEdge server license is imported onto the respective hardware. Importing Azure stack HCI license to a PowerEdge server or PowerEdge server license to an Azure stack HCI server is not supported.
If the problem persists:
  1. Go to iDRAC.
  2. Ensure that Redfish service is enabled.
  3. Disable OS to iDRAC Pass-through and then enable it.

    For more information about enabling or disabling OS to iDRAC Pass-through, see iDRAC user guide.

Logs

Availability of OMIMSWAC extension logs

The OpenManage Integration with Microsoft Windows Admin Center (OMIMSWAC) extension logs of target nodes and cluster nodes are available at <Windows Directory>\Temp\OMIMSWAC on target nodes. The logs capture information when the OMIMSWAC functionalities are run and also provide debug information about any errors that occur while performing any OMIMSWAC operations. The logs of various OMIMSWAC functionalities can be easily accessed with the help of the following naming convention:
  • For hardware and health inventory: Inventory<ID*>
  • For update compliance: FirmwareCompliance<ID*>
  • For update notifications: Notification<ID*>

Availability of update operation logs

The application logs for the update compliance feature is available at the following path:
  • Gateway system: <Windows Directory>\ServiceProfiles\NetworkService\AppData\Local\Temp\generated\logs
  • Windows 10 gateway system: <Windows installed drive>\Users\<user_name>\AppData\Local\Temp\generated\logs
Online catalogs download status is captured in the application logs and can be used to troubleshoot any download errors in the online catalogs.
When online catalog source is selected, and if DSU and IC are not configured in settings in advance, OMIMSWAC will download the catalog, DSU, and IC utilities in the following path:
  • Gateway system: <Windows Directory>\ServiceProfiles\NetworkService\AppData\Local\Temp\generated\Share\temp\<server/cluster_name>
  • Windows 10 gateway system: <Windows installed drive>\Users\<user_name>\AppData\Local\Temp\generated\Share\temp\<server/cluster_name>
Ensure that the downloaded catalog file, DSU, and IC are not modified during compliance generation and update. The catalog file, DSU, and IC utilities are automatically removed after the compliance report is generated and updated.

Logs for pre-update script running on HCI clusters to put storage into maintenance mode are available at <Windows Directory>\Temp\precau.log on each node. And logs for post update script running on HCI clusters to restore storage from maintenance mode are available at <Windows Directory>\Temp\postcau.log on each node.

Availability of licensing logs

The license related logs are available at the following path and can be found by searching DellLicenseCollection in the Cleanup file.
  • Gateway system: <Windows Directory>\ServiceProfiles\NetworkService\AppData\Local\Temp\generated\logs\CleanupXXXXXXXXXXXXXX.log
  • Windows 10 gateway system: <Windows installed drive>\Users\<user_name>\AppData\Local\Temp\generated\logs\CleanupXXXXXXXXXXXXXX.log

Health, hardware, and iDRAC inventory

Unable to fetch the health and hardware inventory from iDRAC

To fetch the health and hardware inventory information from iDRAC, ensure that:
  • Target node is not in the reboot state and is powered on.
  • YX3X and YX2X models of PowerEdge servers are updated with latest iDRAC version of 2.60.60.60 or later.
  • YX4X models of PowerEdge Servers are updated with latest iDRAC version of 3.30.30.30 or later.
  • There are no proxy settings configured on the target node that might conflict with the USB NIC IP address that is configured in OS to iDRAC Pass-through in the iDRAC. If the proxy setting is configured, do the following to exclude the USB NIC IP address:
    1. In the target node, open the Proxy settings.
    2. Under Manual proxy setup, type 169.254.* to exclude the USB NIC IP address configured in the OS to iDRAC Pass-through settings.
  • Firewall on the target node allows inbound connections on port 445. For more information, see Port configuration on the target server. After the port is allowed, if you still see that the inventory has failed, check if the administrative share in the target node has been removed. Removing the administrative share will disable the port 445 thus failing the inventory. Therefore, ensure that the administrative share in the target node is not stopped.
  • The USB NIC adapter is not disabled on the target node operating system.
  • Before you launch Dell OpenManage Integration extension in Windows Admin Center, ensure to log in to WAC as a gateway administrator.
  • PS-Remoting is enabled.
  • Lifecycle Controller is available on the target node.
  • The lockdown mode is disabled on target node.
  • IPMI drivers are present in the target node and the IPMI service is running.
  • CA and CN are disabled on the target node iDRAC.
  • For management of clusters, all the cluster nodes are reachable using IP address, Hostname, and Fully Qualified Domain Name (FQDN) before managing the cluster with OMIMSWAC.
  • If the Redfish service is disabled, enable the Redfish service by using the iDRAC UI. After Redfish is enabled, if this issue persists, check the number of iDRAC sessions opened in the iDRAC UI. If there are eight iDRAC sessions, terminate a few sessions and try again because iDRAC allows up to eight sessions. To view and terminate iDRAC sessions, see the iDRAC documentation on Dell support site.
  • User slots are available on iDRAC to create new users.
  • The PowerShell execution policy is set to RemoteSigned on the system with Windows Admin Center installed and on the target node operating system. For more information, see https://www.dell.com/support/article/sln318718/dell-emc-openmanage-integration-with-microsoft-windows-admin-center-omimswac-fails-to-query-host-information.

Health and hardware inventory of YX2X, YX3X, and YX4X models of PowerEdge servers not displayed

  • Ensure that YX3X and YX2X models of PowerEdge servers are updated with latest iDRAC version of 2.60.60.60 or later.
  • Ensure that YX4X models of PowerEdge Servers are updated with latest iDRAC version of 3.30.30.30 or later.

Overall health status shows warning or critical while health status of node components shows healthy

The overall health status of PowerEdge servers, failover clusters, and HCI clusters might be displayed as critical or warning even if the components of the nodes that are displayed on the Windows Admin Center are healthy. Because the health status of physical disks that are attached to embedded SATA controller may be displayed as Unknown as iDRAC is unable to get the health information for these disks.

For more details on the components in critical health state, go to the respective iDRAC console.

Unable to create users on target iDRAC device

If the lockdown mode (or infrastructure lock) is enabled on PowerEdge Servers with iDRAC firmware below 4.40.00.00, inventory of health, hardware, and iDRAC fails with the error: “Unable to create users on target iDRAC device.”

Resolution: Do one of the followings:
  • Upgrade the iDRAC firmware to 4.40.00.00 or above.
  • Disable the infrastructure lock by navigating to Security > iDRAC Security tab.
  • You can also disable the lockdown mode by navigating to the target node iDRAC UI.

Unable to initialize the OMIMSWAC extension.

Retrieving inventory from servers and cluster nodes may fail with the error: Unable to initialize the OMIMSWAC extension.

Resolution: Ensure that the IPMI driver is installed, and the IPMI service is running on the target node. For more information on the requirement and solution, see Dell OpenManage Integration With Microsoft Windows Admin Center (OMIMSWAC) fails to query host information.

Why is the inventory details not displayed for a few of the cluster nodes?

While monitoring Storage Spaces Direct cluster using OMIMSWAC extension, the inventory and health data for few of the servers may not load. In this case, reset the iDRAC and rerun the inventory/health data.

Why is the inventory details not displayed when the extension is opened in a new browser session?

The credentials are retained only for the current browser session. If you open a new browser session, ensure to reconnect the cluster/target node by selecting 'manage as' and provide administrator credentials when prompted.

Why does health and inventory status for a few components show as 'unknown'?

The health and inventory status for software storage controllers and physical disks that are attached to embedded SATA controller are displayed as "Unknown" as iDRAC is unable to get the health and inventory information for these disks.

Why the inventory information remains in a loading state for a long time?

If the inventory information remains in a loading state for a long time, check the followings:
  • A custom firewall incoming rule could have been created on the target node to block the port 445, which could cause the system inventory to be in the loading state for a long time. Disable the rule to allow the system to pull the inventory information from the target node.
  • While refreshing the inventory information, if a target node/cluster is rebooted or powered off, the inventory information may remain in a loading state for a long time. To load the inventory information, reconnect the target node/cluster after the target node/cluster is available.

Blink and Unblink

Unable to complete or select the disks for the blink or unblink operations

  • Cause: The Redfish service is not enabled.

    Resolution: Enable the Redfish service by using iDRAC UI. For more information, see the iDRAC documentation on Dell support site.

  • Cause: After the hardware inventory is loaded in OMIMSWAC, if the physical disk is removed then the blink and unblink operations fail with error: Blink may not be supported with <Disk_Name>.

    Resolution: Insert the physical disk and click Refresh to reload the inventory information in OMIMSWAC, and rerun the blink and unblink operations.

  • Cause: If the iDRAC firmware version is less than 3.30.30.30, the physical disks cannot be selected to blink or unblink.

    Resolution: Update the iDRAC firmware to the latest version and retry the blink and unblink operations.

  • Blink and unblink operations fail when a physical disk is attached to an embedded SATA controller and the health status is Unknown, indicating that blink or unblink operation may not be supported on the disk.

Cluster-Aware Updating

Update failed

During hardware updates using DSU 2.0.2 and IC invcol_T4M1J_WIN64_23_03_00_44_A00, server update or Cluster-Aware Update may fail.

Resolution:When selecting or unselecting components in the Fix Compliance window, ensure to unselect the below components and then proceed with the update.
  • Firmware for - Disk 5 in Backplane 1 of PERC H740P Adapter Controller 0 in Slot
  • NVMePCISSD Model Number: Dell Express Flash PM1725a 800GB SFF
  • Firmware for - Disk 3 in Backplane 1 of PERC H740P Adapter Controller 0 in Slot 1
  • [0009] Broadcom NetXtreme Gigabit Ethernet #5
  • [0008] Broadcom NetXtreme Gigabit Ethernet #6
  • [0004] Broadcom NetXtreme Gigabit Ethernet #2
  • [0007] Broadcom NetXtreme Gigabit Ethernet #3
  • [0001] Broadcom NetXtreme Gigabit Ethernet
  • [0006] Broadcom NetXtreme Gigabit Ethernet #4
  • [0580] QLogic FastLinQ QL41162-DE 10GbE Adapter #580
  • [0581] QLogic FastLinQ QL41162-DE 10GbE Adapter #581

Job failed while downloading the required components for the update compliance operation

While downloading the DSU and IC tools, the update jobs may fail due to various reasons. Probable causes and solutions are given below:

  • Cause: While exporting the repository by using Dell Repository Manager (DRM), the export job may complete with status as "Partially succeeded." In this case, one or more DUPs may be missing from the repository.

    Resolution: Retry exporting the repository in DRM and ensure that the job is successfully completed.

  • Cause: One or more components may not be downloaded when the 'update source' is selected as an online source.

    Resolution: Ensure that there is Internet connectivity and retry downloading the catalog from the online source. For more information, see Dell Repository Manager user guide.

Unable to download the DUP(s)

When accessing Windows Admin Center (WAC) locally with domain credentials, DUP downloads may fail during target node or cluster updates.

Resolution: Ensure the followings:

  • You are logged in to Microsoft Windows Admin Center remotely using domain administrator credentials. Ensure that the credentials are part of Gateway Administrator. For more information, see Microsoft documents.
  • Check your Internet connection or proxy configuration.

Unable to generate compliance report

  • Before generating the compliance report, ensure that:
    • Network connectivity between the gateway system and the target node is intact.
    • Target node is not in reboot or powered-off state at the time of compliance generation.
    • Firewall does not block the communication between the Windows Admin center and shared location through SMB port 445. Ensure the port 445 is enabled from firewall inbound rule in the respective target nodes.
    • You are using a valid catalog for update compliance. Ensure that the catalog is created by using the Dell Repository Manager (DRM) application and the catalog contains firmware for specific servers.
  • Cause: When you connect to a target node or cluster using Single-Sign-on rather than 'Manage as' and generate compliance report using OMIMSWAC, the compliance generation may fail.

    Resolution: Before connecting to the target node or cluster, ensure that you select "Manage as" and provide appropriate Server Administrator or Cluster Administrator accounts.

  • Cause: When generating a compliance report, the compliance report generation may fail with the following error in the log:
    Starting a command on the remote server failed with the following error message : The WinRM client sent a request to the remote WS-Management service and was notified that the request size exceeded the configured MaxEnvelopeSize quota. For more information, see the about_Remote_Troubleshooting Help topic.
    Resolution: Ensure that:
    • File copying works between the gateway system and the target node. To check this:
      1. Create a session based on target node credential by running the following PowerShell command:

        $SecurePassword = convertto-securestring <password> -asplaintext -force

        $credential = New-Object System.Management.Automation.PSCredential -ArgumentList <userid>, $SecurePassword

        $session = New-PSSession -ComputerName <MN FQDN> -Credential $credential -ErrorAction SilentlyContinue

      2. Copy a test file to the failed target node assuming "Test.txt" is in C:\ drive

        Copy-Item -Path "C:\Test.txt" -Destination "C:\" -Recurse -Force -ToSession $session

      3. If the issue still persists, check if the file copy operation fails due to insufficient maxevenlopesize set at the Powershell. In this case, ensure that the maxevenlopesize size is increased by using this command: Set-Item -Path WSMan:\localhost\MaxEnvelopeSizekb -Value 8192. See the Microsoft document.
  • Cause: When generating a compliance report for a cluster, the compliance report generation may fail for cluster nodes.

    Resolution: Ensure that:

    • The cluster service is running on the cluster node by using the Get-ClusterService PowerShell command.
    • The cluster node is not rebooting or in the powered-off state.
    • When adding a cluster to the Windows Admin Center, ensure to use the cluster name in FQDN format.
  • Cause: When generating a compliance report using Windows 10 Microsoft Edge browser, the compliance report generation may fail with the following error: Unable to generate compliance report. The Manage As credentials have not been set or are not in domain\user format.
    Resolution: Do any of the followings:
    • Connect the target node with credentials using Fully Qualified Domain Name (For example, domain.lab\username) or Top Level Domain (For example, domain\username).
    • Clear the cache memory of the browser and rerun the compliance.
    • Ensure that the DNS is configured properly in the WAC installed system to connect to the target node with right credentials.
  • Cause: Compliance report generation may fail with the following error Unable to install Dell System Update(DSU) package for the server/cluster because DSU installation operation is already in progress for another server/cluster. This occurs because, a user may be trying to run compliance concurrently from two different instances/sessions. For example, one instance by clicking the pop-out button and another instance by using the browser from the same gateway simultaneously. One of the instance/sessions that was triggered first proceeds for compliance/update; while another results in an error.

    Resolution: Run only one compliance/update for a target node/cluster at a time using one gateway instance.

Compliance report page on loading state for a long time

During compliance generation, the compliance report page may sometimes appear in the loading state even after the notification says that the compliance report is successfully generated.

In this case, go to any of the other tabs such as "Settings", "Inventory", and so forth,, and then come back to the Update tab, where you will see the generated compliance report.

Job failed while updating the selected components

Sometimes, CAU or target node updates may fail due to various reasons. The causes and resolutions are given below:

  • Causes: If target nodes are not validated before triggering CAU, the CAU may fail.

    Resolution: For Cluster-Aware Updating, ensure to validate the cluster before triggering CAU. For more information about validating a cluster, see Microsoft document Validate Hardware for a cluster.

  • Causes: If Failover Clustering feature and Failover Clustering Tools are not installed on target nodes, the CAU may fail.

    Resolution: As OMIMSWAC uses the Microsoft Cluster-Aware Updating feature framework to perform cluster updates, before updating a cluster using OMIMSWAC, ensure that the Failover Clustering feature and Failover Clustering Tools are installed on all the target nodes. For more information, see CAU requirements and best practices in Microsoft documents.

    To check whether failover clustering tools are running on all the target nodes, from the PowerShell window on the target node, run the Get-CauClusterRole PowerShell command.

  • Cause: Compliance Inventory file is not available for some nodes or file copying from node to gateway is failed after compliance generation.

    Resolution: Rerun the compliance.

  • Cause: Due to Internet connectivity issue, the followings may fail:
    • Signature verification of DSU or IC
    • Downloading of online catalog
    • Downloading of DUP

    If any of the above fails, CAU or server update also fails.

    Resolution: Ensure that there is Internet connectivity and rerun compliance and update.

  • Cause: DSU installer is not cleared from a node because the installer file sometimes gets locked by the Windows Admin Center process (sme.exe).

    Resolution: Restart the Windows Admin Center service from Windows Services consoles.

  • Cause: CAU fails if any of the disks is not in healthy state.

    Resolution: Ensure both physical, and virtual disks are in healthy state before triggering CAU. If any disk is in an unhealthy healthy state, see the Microsoft document to get it to a healthy state.

  • Cause: CAU fails if any of the cluster nodes is paused.

    Resolution: Resume cluster nodes (Failover roles) before triggering CAU.

  • Cause: CAU fails when Failover Clustering feature and Failover Clustering Tools are not installed on all the target nodes.

    Resolution: Ensure Failover Clustering feature and Failover Clustering Tools are installed on all the target nodes before performing CAU. For more information, see https://docs.microsoft.com/en-us/windows-server/failover-clustering/cluster-aware-updating-requirements.

CredSSP Failure
Check the event viewer logs in the gateway system to ensure that CredSSP has not failed during Cluster-Aware Updating. If the CredSSP fails, following are the probable causes and solutions:
  • Cause: While updating a cluster, credential delegation using CredSSP may fail.

    Resolution: Reconnect the cluster using fully qualified domain name, and click Use this credential for all servers check box.

    For example, if the domain name is test.dev.com, use test.dev.com\administrator as the domain name, and then click Use this credential for all servers check box.

  • Cause: When using CredSSP authentication to run scripts on a remote machine, the update job may fail with an error.

    The issue is because CredSSP has been disabled in the gateway machine.

    Resolution: To resolve the issue, follow the steps below:
    1. From PowerShell window, run gpedit
    2. In the Group Policy Editor window, Computer Configurations > Administrative Templates > System > Credentials Delegation
    3. Select Allow delegating fresh credentials with NTLM-only server authentication and enable it.
    4. Run gpupdate /force in the PowerShell.
Dell Update Package failures
The Dell Update Package (DUP) may fail to update components after you trigger an update. There are various reasons for the DUP to fail during the update. Look at the following possible solutions to resolve the issue:
  • In Windows Admin Center (WAC) installed machine, check the log files to get more information regarding DUP download failure and component mapping. The component mapping is provided to identify the component (selected for update) in the DUP catalog. The log files are at the following path.

    Gateway system:

    • Server update: <Windows Directory>\ServiceProfiles\NetworkService\AppData\Local\Temp\generated\logs\<PrepareUpdate XXXX>
    • CAU: <Windows Directory>\ServiceProfiles\NetworkService\AppData\Local\Temp\generated\logs\Update XXXX
    Windows 10 gateway system:
    • Server update: <Windows installed drive>\Users\<user_name>\AppData\Local\Temp\generated\logs\<PrepareUpdate XXXX>
    • CAU: <Windows installed drive>\Users\<user_name>\AppData\Local\Temp\generated\logs\Update XXXX
  • Sample log messages are given below:
    • DUP download failure error log

      28-Apr-2020 12:19:18 AM::: Error >>> Message : DUPs for some of the selected components are not present in DRM repository.

    • Component mapping log file

      ## Format: :>> Component Name -> Package Name

      :>> [0001] Broadcom NetXtreme Gigabit Ethernet -> Network_Firmware_RG25N_WN64_21.60.2_01.EXE

  • In the target node, refer component mapping and find the component related DUP log file and check the return code that is specified in <Windows Directory>\Dell\UpdatePackage\log\<Package Name>. See Dell Update Package user guide for cause and possible resolution.

    A return code sample of a DUP failure scenario is given below:

    Exit code = 1 (Failure)

    2020-04-21 23:48:27

    Update Package finished. Exit code = 1

  • The DUP may fail when attempting to downgrade a driver component to a lower version. In this case, uninstall the driver from the operating system and then rerun the component update from OMIMSWAC. For more information about how to uninstall drivers, see Microsoft document.
Alternatively, you can also try the followings:
  • Reset and update the iDRAC to version 4.20.20.20 or higher and then rerun the update. For more information about how to Reset or update iDRAC, see iDRAC documentation.
  • Run the update manually in the target node by downloading from the path specified in <Windows Directory>\Dell\UpdatePackage\log\<Package Name> in the DUP log. Example for a network firmware is https://downloads.dell.com/FOLDER06091050M/1/Network_Firmware_TWFF6_WN64_16.26.60.00.EXE.
  • Ensure that the selected DUP is supported on the selected operating system and platform by searching the component name in the Dell Support site. Dell support site URL: https://www.dell.com/support/home/in/en/inbsd1/?app=products.

Why are some of the components shown as non-compliant even when the cluster update is successful?

  • Below components may show as Non-compliant even when the cluster/target node update is successful. This happens with target nodes running on Windows server 2022.
    • SM Bus Controller Driver
    • Chipset INF
    Resolution: Run Get-PnpDevice -PresentOnly | Where-Object {($_.Status -ne 'OK') -and ($_.Problem -ne 'CM_PROB_NONE' -and $_.Problem -ne 'CM_PROB_DISABLED')} to check if Chipset Drivers installed. If they are not installed, download and install the AMD Chipset Driver manually.
  • After a successful cluster update, you may see components showing as non-compliant. This happens because of DUP failure.

    Resolution: In this case, check the cleanup logs having the DSU logs to see if there is any ERROR for those components. If there is any prerequisite that is required for the component before update, follow the prerequisite and then rerun the update.

Why updating server/cluster running on Windows Server 2016 operating system may sometimes fail?

Cause: If you update a target node or cluster running on Windows Server 2016 operating system using online catalog, the update job may fail. This is because the default selected below components is not part of the target node/cluster.
  • Chipset INF
  • PERC H745 Adapter Driver
  • Broadcom NeXtreme-E Driver Family

Resolution: Make you clear the component selection in the Compliance Report page while proceeding for update. If the issue persists, see "Job failed while updating the selected components" in the section to troubleshoot further.

Unable to trigger update for Azure Stack HCI cluster (version 22H2) outside of OMIMSWAC

Cause: While updating a Azure Stack HCI cluster version 22H2, OpenManage Integration extension changes the CAU clustered role settings and keeps a backup of the previous settings in each cluster node. Due to change in CAU clustered role settings, the cluster update may not trigger if performed outside of the OpenManage Integration extension. This issue does not impact any cluster node configuration.

Resolution: Before attempting an update outside of the extension, run the below PowerShell command in one of the cluster node to revert the CAU clustered role configuration of the cluster to the values provided by CAU. Previous backup settings are stored in each node at C:\Windows\Temp path with the name CauClusterRoleBackup_<YYYYMMDDHHmmSS>.xml. Provide the path and file name in the following script and then run the command.
$cauClusterRoleBackupFilePath = 'C:\Windows\Temp\cauclusterrolebackup_20221202.xml'
function HasKey([hashtable]$hash, [string]$key){
    if ($hash.Keys -contains $key) {return $hash[$key]} else {return $null}
}
$cr = Import-Clixml -Path $cauClusterRoleBackupFilePath
$htCr = @{}
$cr | ForEach-Object {$htCr.Add($_.Name, $_.Value)}
Set-CauClusterRole -CauPluginArguments ([hashtable[]](HasKey -key 'CauPluginArguments' -hash $htCr)) -MaxFailedNodes ([int](HasKey -key 'MaxFailedNodes' -hash $htCr)) -MaxRetriesPerNode ([int](HasKey -key 'MaxRetriesPerNode' -hash $htCr)) -PreUpdateScript ([string](HasKey -key 'PreUpdateScript' -hash $htCr)) -PostUpdateScript ([string](HasKey -key 'PostUpdateScript' -hash $htCr)) -RebootTimeoutMinutes ([int](HasKey -key 'RebootTimeoutMinutes' -hash $htCr)) -Force -ErrorAction Stop

Full Stack Cluster-Aware Updating

Couldn't configure cluster aware updates

Cause: To perform full stack updates, in Windows Admin Center, when you select Updates from the Tools menu, an error might occur: Couldn't configure cluster aware updates. This error occurs because CAU clustered role could not be added to the cluster for update.

Resolution: As a workaround, you can add the cluster role manually using the following PowerShell command before triggering the full stack update: Add-CauClusterRole -StartDate "02-03-2021 3:00:00 AM" -DaysOfWeek Tuesday -WeeksOfMonth 3 -EnableFirewallRules -RequireAllNodesOnline -Force

For more information, see Configure the nodes for remote management in Microsoft documents.

Couldn't query readiness for cluster aware updates

Cause: To perform full stack updates, in Windows Admin Center, when you select Updates from the Tools menu, an error might occur: Couldn't query readiness for cluster aware updates. This error occurs because of CredSSP failure.

Resolution: As a workaround, see CredSSP failure to find the cause and solution.

For more information, see the Microsoft document.

Tests Summary page appears

While triggering full stack updates, Tests Summary page may appear.

Resolution: As a workaround, verify if pre-update or post-update script are part of the cluster role. If present, remove the scripts from the cluster node by running the following command in PowerShell: Set-CauClusterRole -PreUpdateScript $null -PostUpdateScript $null. For more information about prerequisites required for cluster update, see the Microsoft document.

Update status takes longer to refresh

During full stack cluster updates, the update status that is shown in the Updates page may take longer to refresh. In this case, it is recommended to stay on the Updates page and wait for the update to complete. The update status will automatically be displayed once the update is complete. For more information about Microsoft recommendations, see the Microsoft document.

Full stack update may fail with failover cluster tool extension 1.271.0 nupkg

During full stack cluster updates in Azure Stack HCI clusters, the update may fail with an exception Error: RemoteException: Exception calling "Add" with "2" argument(s): "Item has already been added. Key in dictionary: 'PreUpdateScript' Key being added: 'PreUpdateScript'". This issue occurs when Microsoft Failover Cluster Tool Extension 1.271.0 is installed. Due to this issue, both hardware and operating system cluster-aware updates (Full stack update) cannot be performed together.

Resolution: Use the latest Microsoft Failover Cluster Tool Extension to perform full stack updates using OMIMSWAC.

Unable to communicate to target node

In WAC, when you click Update extension to initiate full stack update, the prerequisites check may fail with 'Unable to communicate to target node' error message. This may happen because:
  • Target node may be in a reboot or powered off state. Ensure that the target node is not in reboot or powered-off state.
  • Firewall does not block the communication between the Windows Admin Center and shared location through SMB port 445. Make sure the port 445 is enabled from firewall inbound rule in the respective target nodes.
  • Also, if multiple connections are selected from the "All connections" page and "Manage as" credentials entered without selecting the "Use this credential for all connections" check box, this error may appear. In this case, go back to the "All connections" page, reconnect the specific cluster by entering "Manage as" credentials and then try running full stack update.

Duplicate cluster node appears during full stack update

While performing full stack update, if you exit during the hardware updates and check the "All connections" page in the Windows Admin Center, you may notice duplicate cluster nodes. You cannot perform any operations selecting the duplicate node. Reload the browser to remove the duplicate nodes.

How do I perform hardware updates as part of full stack update if "Quality updates only" is missing?

In WAC, "Quality updates only" (Updates > Available update) includes both operating system and hardware updates. If there are no quality updates (operating system update) available, you may not find the "Quality updates only" button in the Windows Admin Center. In this case, if you want to perform hardware updates, go to the OpenManage Integration and connect to the cluster to perform the cluster update in cluster-aware manner.
NOTE:
As part of full stack update process, Dell recommends performing the hardware updates after you perform the operating system updates from UpdatesAvailable update.

Why Azure, Expand Storage, and HCP Compliance features are disabled in Azure Stack HCI cluster v2?

Cause: After Azure Stack HCI cluster v1 is updated to Azure Stack HCI cluster v2 using the Microsoft Update tool, you may find the OpenManage Integration extension features such as Azure, HCP Compliance and Storage expansion are blocked with an error banner message.

Resolution: Ensure that all updates are installed and no updates are in a pending state.

Manage CPU core

Job failed while updating CPU core configuration

Applying CPU core configuration changes may fail due to various reasons. The causes and resolutions are given below:

  • Causes: If the cluster is not validated as per Microsoft recommendations before applying CPU core changes, updating CPU core changes may fail.

    Resolution: Before updating CPU core changes ensure to validate the cluster. For more information about validating a cluster, see Microsoft document Validate Hardware for a cluster.

  • Causes: If Failover Clustering feature and Failover Clustering Tools are not installed on target nodes, updating CPU core changes may fail.

    Resolution: As OMIMSWAC uses the Microsoft Cluster-Aware Updating feature framework to perform cluster updates, before updating a cluster using OMIMSWAC, ensure that the Failover Clustering feature and Failover Clustering Tools are installed on all the target nodes. For more information, see CAU requirements and best practices in Microsoft documents.

    To check whether failover clustering tools are running on all the target nodes, from the PowerShell window on the target node, run the Get-CauClusterRole PowerShell command.

  • Cause: After CPU core updates are applied in a cluster, rebooting of nodes may fail if any of the disks is not in healthy state.

    Resolution: Ensure both physical and virtual disks are in healthy state before updating CPU core configurations. If any disk is in an unhealthy healthy state, see the Microsoft document to get it to a healthy state.

  • Cause: CPU core update fails if any of the cluster nodes is paused.

    Resolution: Resume cluster nodes (Failover roles) before updating CPU core configurations.

  • Cause: While applying the CPU core changes, one of the cluster nodes may be forcefully or accidentally shut down.
  • Cause: Health and hardware inventory from target node iDRAC could not be retrieved.

    Resolution: For more information, see unable to fetch the health and hardware inventory from iDRAC.

CredSSP Failure
Check the event viewer logs in the gateway system to ensure that CredSSP has not failed during CPU core configuration update. If the CredSSP fails, following are the probable causes and solutions:
  • Cause: While updating CPU cores, credential delegation using CredSSP may fail.

    Resolution: Reconnect the cluster using fully qualified domain name, and click Use this credential for all servers check box.

    For example, if the domain name is test.dev.com, use test.dev.com\administrator as the domain name, and then click Use this credential for all servers check box.

  • Cause: When using CredSSP authentication to run scripts on a remote machine, the update job may fail with an error.

    The issue is because CredSSP has been disabled in the gateway machine.

    Resolution: To resolve the issue, follow the steps below:
    1. From PowerShell window, run gpedit
    2. In the Group Policy Editor window, Computer Configurations > Administrative Templates > System > Credentials Delegation
    3. Select Allow delegating fresh credentials with NTLM-only server authentication and enable it.
    4. Run gpupdate /force in the PowerShell.

Applying CPU core changes failed

Applying CPU core changes status may show as failed in individual nodes because during CPU core changes:
  • OMIMSWAC is unable to connect to the node.
  • CPU core update session is disconnected.
  • Rebooting of the node is stuck.

Can I update CPU core configurations in Failover cluster?

No, updating CPU core configurations is not supported in Failover clusters. It is supported only on Azure Stack HCI clusters and Windows Server based HCI clusters.

Can I update CPU core configurations in individual nodes?

Yes, you can update CPU core configurations in individual nodes. However, the node should not be part of an Azure Stack HCI cluster or Windows Server based HCI cluster. Nodes part of Failover clusters are supported for individual CPU core configuration update.
NOTE: Dell highly recommends to keep hardware configuration same across all cluster nodes to achieve optimal performance. If you update CPU core configuration in one node in a failover cluster, ensure to maintain the same configurations across all nodes in the cluster.

Do I need a license installed to update the CPU core configuration?

Yes, "OMIWAC Premium License for MSFT HCI Solutions" must be installed on each cluster node to update CPU core configurations. For individual nodes, OMIWAC Premium License must be installed for individual CPU core update. For more information about licenses, see OpenManage Integration with Microsoft Windows Admin Center Licensing.

Cluster Expansion

Signature verification failed with the provided support matrix details

(optional) If Internet connection is not available, perform the below steps to run HCI configuration profile checks in offline mode:
  1. Download the asHCISolutionSupportMatrix.json and asHCISolutionSupportMatrix.json.sign files from https://downloads.dell.com/omimswac/supportmatrix/.
  2. Place these files in C:\Users\Dell\SymmetryCheck folder in the gateway system where Windows Admin Center is installed.
  3. Go to Windows Admin Center cluster connection home page, connect to the cluster and then launch to Dell extension again.
  4. In the OpenManage Integration, go to the Configure tab and then click Expand Cluster on the left side.

Node update fails during node preparation for cluster expansion

During node preparation for cluster expansion, if node update fails due to SAS-RAID_Driver, ensure the followings configurations are set:
  • Set the SATA controller to RAID mode.
  • Set the NVMe PCIe SSDs to RAID mode.

    For more information about setting the RAID mode, see Appendix

Secured-core

Operating System security feature status shows critical in OMIMSWAC extension even if it is enabled in the WAC

In the OMIMSWAC extension, the Operating System security features status is displayed based on the secured-core feature status in the WAC Security extension. But sometimes, in the OMIMSWAC extension, Operating System security features status may show as critical, while the same security features are enabled in the WAC Security extension.

Resolution: Run the command misinfo32 from the command prompt to open the Microsoft System Information tool. In the tool, ensure the following:
  • The Secure Boot State value is set to On.
  • The Kernel DMA Protection value is set to On.
  • The Virtualization-based Security value is set to Running.
  • The Virtualization-based security Services Running value is set to Hypervisor enforced Code Integrity and Secure Launch.

After ensuring the above attributes, if the operating system security features status still shows critical, you can ignore it.

Unable to retrieve BIOS/OS feature status

Cause: You may be using YX2X and YX3X PowerEdge servers. Secured-core feature is not supported on these servers.

Resolution: Use supported YX5X PowerEdge servers and try again.

HCP Compliance

Unable to load policy summary report for other nodes when one node is not reachable

While running HCP Compliance checks, if nodes(s) are not reachable, the policy summary displays the compliance report only for infrastructure policy. Compliance reports for other policies are not displayed. Ensure all the cluster nodes are reachable and run the checks again.

Cluster Recommendation

Secured-core attributes non-compliant after applying cluster recommendations

After applying the cluster recommendations, if you find the secured-core attributes are still non-compliant, check if the firmware version of TPM 2.0 module is 7.2.2.0 or above.

Onboard Dell policies to Azure Arc

Why does the compliance of Azure Stack HCI cluster not match with the compliance status in Windows Admin Center?

If you notice that cluster compliance for the Azure Stack HCI cluster in Azure does not match with the latest compliance status of the cluster, go to the iDRAC of individual server and check if any batch job is pending. Ensure the pending job at the iDRAC is completed (if required, restart the server), and then run the compliance again in the Azure to get the correct compliance data.

Compliance status available on different pages in the Azure portal is not consistent

Compliance status for few Dell policies may not match in the Azure portal. Some views in the Azure portal may show compliant, whereas other views may show non-compliant. Please wait for some time and let all the views in the Azure portal sync with the correct compliance status.

Unable to sign into Azure from the Azure tab

While signing in to Azure from the Azure tab, you may see this error Error:could not resolve endpoints. Please check network and try again. Details: function toString() { [native code]} that points to strings and functions.

Resolution: Ensure that Azure has an active Internet connection.

Others

OpenManage Integration access denied

Cause: When you log in to Windows Admin Center (WAC) using gateway user credentials without admin privileges and try to launch OpenManage Integration from the WAC console, access denied error may appear.

Resolution: Before you launch Dell OpenManage Integration extension in Windows Admin Center, ensure to log in to WAC as a gateway administrator.

Test-Cluster fails with network communication errors

Cause: With USB NIC enabled in iDRAC, if you run Test-Cluster command to verify the cluster creation readiness or cluster health, you may see an error in the validation report. The error states that the IPv4 addresses assigned to the host operating system USB NIC cannot be used to communicate with the other cluster networks. This error can be safely ignored.

Resolution: Disable the USB NIC (labeled as Ethernet by default) temporarily before running the Test-Cluster command.

USB NIC network shows as partitioned cluster network

Cause: When the USB NIC is enabled in iDRAC, cluster networks in the failover cluster manager show the networks that are associated with the USB NIC as partitioned. This issue occurs as cluster communications are enabled by default on all network adapters and USB NIC IPv4 addresses cannot be used to communicate externally, thus disrupting cluster communication on those NICs. This error can be safely ignored.

Resolution: Disable cluster communication with the networks associated with the USB NICs from the cluster manager.

Acceptance Failed to save: Dell Technologies Software License Agreement and Customer Notice

Cause: Dell Technologies Software License Agreement and Customer Notice acceptance may fail to save. This may happen when you launch multiple instances of the Dell OpenManage Integration extension from the same gateway, and accept terms and conditions in one instance. In the remaining instances, if you attempt to accept the terms and conditions, you will encounter this error.

Resolution: Navigate away from the Dell OpenManage Integration extension where this issue occurs, and then back in to resolve this issue.

Can I use the Single Sign-on or smart card authentication to log in to OMIMSWAC?

You cannot use Single Sign-on or smart card authentication to log in to OMIMSWAC. To connect to a cluster/server, use 'manage as' and then enter domain or gateway admin credentials.

Why am I not able to access the OMI extension using remote connection?

Without gateway administrator privileges, you cannot access the OMIMSWAC. You can launch the browser and connect to the gateway system using gateway administrator credentials from the remote workstation.

Cluster restarting status does not match with the status showing on the UI

During cluster restarting, the UI displays the status. You may notice some discrepancy between the UI status and the actual operations. For example, when the node is restarting, the UI status may show as "Installing" instead of "Restarting". You can ignore this issue as it does not impact any operations. To check the status, you can see the details of the progress using Microsoft Cluster Aware Updating tool.


Rate this content

Accurate
Useful
Easy to understand
Was this article helpful?
0/3000 characters
  Please provide ratings (1-5 stars).
  Please provide ratings (1-5 stars).
  Please provide ratings (1-5 stars).
  Please select whether the article was helpful or not.
  Comments cannot contain these special characters: <>()\