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


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<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*>Inventory<ID*>
  • For update compliance: FirmwareCompliance<ID*>FirmwareCompliance<ID*>
  • For update notifications: Notification<ID*>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 referred 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.

Unable to copy the required files to the target node to fetch inventory information.

Ensure that:
  • Target node is not in the reboot state and is powered on.
  • Firewall is not blocking communication through SMB port 445. For more information, see prepare your environment for Windows Admin Center.
  • The user is logged in with Gateway Administrative privileges. Before connecting to the target node, ensure that you select "Manage as" and provide appropriate Server Administrator or Cluster Administrator accounts. For more information about selecting "Manage as", see the "Get Started with Windows Admin Center" section in the Microsoft documentation.

Unable to fetch the health and hardware inventory from iDRAC.

To fetch the health and hardware inventory information from iDRAC, ensure that:
  • For management of PowerEdge servers, OMIMSWAC uses an internal operating system to iDRAC Pass-through interface. By default, iDRAC is reachable using the IP address<Subnet> or<Subnet>. However, if the host has another network interface in the same subnet (for example, when tool such as VMFleet is installed), OMIMSWAC might not be able to communicate to the iDRAC from the host operating system.

    To resolve the conflict, log in to iDRAC and change the USB NIC IP address under the operating system to iDRAC passthrough section. For more information about assigning this IP address, see the iDRAC documentation on the support site.

  • 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 iDRAC UI. For more information, see the iDRAC documentation on Dell EMC support site.
  • User slots are available on iDRAC to create new users.

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 EMC 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>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, 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.

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 not in the reboot state and is powered on.
  • 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 a 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.

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

Job failed while downloading the required components for the server and cluster-aware updating operations.

Cause: While exporting the repository by using Dell EMC Repository Manager (DRM), the export job may complete with status as "Partially succeeded." In this case, one or many 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 many 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 EMC Repository Manager user guide.

CredSSP failed during update

  • 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, use\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. Execute gpupdate /force in the PowerShell.

Enabling CredSSP delegation

Cause: When you navigate out of OpenManage Integration to other tools under HCI or Failover solutions and navigate back to OpenManage Integration, the following error is displayed: Enabling CredSSP Delegation.

Resolution: Ignore the error because the functionality of OpenManage Integration and Windows Admin Center is not blocked.

Job failed while generating compliance report

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:
  • Network connectivity between the gateway system and the target node is intact.
  • File copying works between the gateway system and the target node. To check this:
    1. Create a session based on target node credential by executing 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

  • If the problem persists after performing the above actions, try restarting the Windows Remote Management (WS-Management) service in the target node (file copy is failing) then re-run the compliance.

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-ClusterServiceGet-ClusterService PowerShell command.
  • The cluster node is not rebooting or in the powered-off state.

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 the DNS is configured properly in the WAC installed system to connect to the target node with right credentials.

Cause: When you connect to a server or cluster using a password that contains any of the following special characters, and attempt to generate a compliance report using OMIMSWAC, the compliance generation may fail. The special characters are: double-quote ("), grave accent (`), and semi-colon (;).

Resolution: Reset the password by removing special characters and reconnect to the server or cluster.

Job failed while updating the selected components.

Sometimes, CAU or target node update may fail. The causes and resolutions are given below:

  • In case of CAU, validate the cluster before triggering Cluster-Aware Updating. For more information about validating a cluster, see Microsoft document Validate Hardware for a cluster.
  • 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, refer to 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.

Component showing non-compliant after update

After update, you may see components showing as non-compliant.

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

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 EMC OpenManage Integration extension in Windows Admin Center, ensure to log in to WAC as a gateway administrator.

Dell Update Package failures

The Dell EMC 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 specified in <Windows Directory>\Dell\UpdatePackage\log\<Package Name>. See Dell EMC 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 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 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
  • 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:

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 since the cluster communication is enabled by default on all network adapters and USB NIC IPv4 addresses cannot be used to communicate externally, therefore, breaking 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.

Rate this content

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: <>()\