OME - An Exercise in Frustration

Question

I was excited when I first installed OpenManage Essentials. Here was a console that would show all of our servers in one console and make it easy to deploy firmware and driver updates. It was fairly easy for me to set up SNMP, discover and inventory the systems.

But, trying to push updates has been an exercise in frustration. OME will often hang a task with a "Failed" status in a "Running" state. Sometimes a task will fail and be reported as "Complete".

Because OME doesn't support 64-bit DUPs, it tries to send a 32-bit NIC update to a 64-bit server. The tasks "completes" "successfully" with the result "This installation package is not supported by this processor type. Contact your product vendor."

Here's the result from a "Failed" task that is still running and will "run" forever:

Update Failure: Unified Server Configurator Failure - Detach USC failure - Detaching a partition has failed
TotalStatus Unknown exception occurred during system update.
TotalStatusMessage Software update in-progress.

I cannot believe how much of a failure OME is. I had high hopes that it would work as well as the Server Update Utility. With SUU, I run it, it lists the updates that are needed, I select to install them, they install, then I reboot the server. Then when the server boots back up, the updates are...wait for it...actually installed! The down side to SUU is that it is a manual process.

Maybe one day OME will actually be able to install updates, or get it right when it tells me if something has installed or not, or get it right to know if something is running or not. Until then, I weep with sadness.

DELL-Rob C · Answer

Thanks MK for taking the time to write the post.

In addition to PPrabhu questions, i just wanted to point out that although the DUPS are 32 bit, they carry a 64 bit driver payload. Of course some 32 bit DUPS do carry 32 bit drivers, which is why we are checking on the DUP name. (Apologies if you understand this distinction already, some folks may not).

Again, thanks for the post.

Rob

Dell-PPrabhu · Answer

We really hope to improve your user experience and put the days of sadness behind you. I understand running updates can be frustrating and customer reports such as yours only help us get better with our handling of DUPs and the update process overall.

Unfortunately sometimes the issue is with the DUPs and that is not obvious from the error messages seen. OME doesn't have any logic that is specific to a type of DUP.

Can you please let us know:

- The version of the OME

- The exact name of the DUP

- The model of the target server being updated

- The OS on that target server

PPrabhu

MK1024 · Answer

Another thing I noticed which may or may not be a problem is with the NIC firmware updates. If there are two NICs in the system, selecting one firmware update in SUU would automatically select the second. It was impossible to update the firmware of only one of the NICs.

I'm not seeing this behavior in OME. I have a few systems in OME listing two identical NIC firmware updates and it is allowing me to select one individually. I don't know if trying to update just one will update both or if something else would happen.

MK1024 · Answer

Thanks for following up. The version of OME is 1.3.0.1533.

It turns out that I was wrong about the 64-bit issue. The update that "succeeded" with the error of "This installation package is not supported by this processor type" is not running a 64-bit OS. I had made an assumption that the OS must be 64-bit because that's the only case when I've seen an error like this. I tried running the DUP manually on the server and it did pop up a message box with that text.

Here are the requested details:

Deployment Error: This installation package is not supported by this processor type.
Name of the DUP: Network_Driver_GPJ8K_WN_18.2.2_17.8c.4.3.EXE
Model of the target server: PowerEdge R300
OS on that target server: Windows Server 2008 Standard x86

Deployment Error: Unified Server Configurator Failure - Detach USC failure - Detaching a partition has failed; TotalStatus Unknown exception occurred during system update.
Name of the DUP: R710_Drivers-for-OS-Deployment_Application_M5VGR_WN32_7.4.0.10_A00.EXE
Model of the target server: PowerEdge R710
OS on that target server: Microsoft Hyper-V Server 2008 R2 (i.e. a Server Core installation)
Notes:
- The update task started on 05/16/2014 is still showing as both "Failed" and "Running" with a 50% status.
- This server is now showing as "Compliant" in OME. Maybe the update did take over the weekend.

Another issue I'm having is that we have some MD1000s. OME is recommending upgrading to an available firmware of "A04" after it detects an installed version of "A.04".

I would really like to see OME provide more reliable feedback. In my two tests, I had a task "Fail" and be left listed as "Running" and a task "Succeed" that actually failed.

I'd also like it if OME could automatically run an inventory after completing an update task. It looks like it's not doing this now. For my tests, I wanted to run updates now and see the results. To have an update complete and still have the system show as non-compliant and needing the update isn't a good user experience.

SUU is able to provide pretty good feedback. So, it should be possible for OME to improve in this area even though it's dealing with DUPs not necessarily designed for it.

TRScott · Answer

I know that with my ESXi hosts that it does re inventory them when I push a package out to them, and since we have about 25 physical servers left in our network I don't really ever see the issue that you're talking about when you say that it isn't re running the inventory task.

I don't know why sometimes the iDRAC and host IP's don't "link" up in my case and that's been an ongoing issue for me with a lot of my ESXi boxes with no resolution to date to make it "never" happen again, this dates back to OME 1.1 and I'm now on 1.3.

I do hope that they put more time and effort into it without making it a pay software, as I'm not sure our IT budget would purchase it :( It is great for keeping our servers up to date without much effort or interruption in service.

DELL-Pupul M · Answer

Will it be possible for you to attach a screenshot of how it looks like in the device tree? It should help in figuring out what is going wrong. Please elaborate on which is the RAC and which is the server for that RAC in the screenshot.

DELL-Pupul M · Answer

Hi TRScott,

For your ESXi problem, not sure if there is already a post, but do you see the RAC information table populated in the ESXi discovery when your RAC and server do not correlate? Also, by any chance it is possible that these IPs change over time?

TRScott · Answer

All server and switchgear on our network is statically assigned, so no they won't and don't change over time.

When they don't "merge" together in my non compliant tab under system update I show the idrac and not the server name. When I go to the devices tab I see idrac of one of the servers but the other only shows under the ESXi servers listing and not under the RAC listing.

I've called into support multiple times for this, and some of my esxi hosts just up and disappearing, which results in us taking the range out and only discovering the one host to link it together then repopulating the range once that is done, which works for a while then it breaks again.

I do like OME but the constant need for attention is a definite annoyance for me personally, I just don't understand why it randomly seems to take a dump and lose information.

TRScott · Answer

Here is the RAC (which should say VSE-ATGA-ESX01) but it is only showing the iDRAC name.

Then we have this one under the HOST folder which shows the ESXi server but there is no corresponding iDRAC associated with it when it has one.

And this is in the compliant tab under system update which shows the iDRAC of the SHO server by IP only.

This is the iDRAC for the ATGA server in the non compliant tab.

But this is the last job and it says it can't run over the iDRAC, so why does it show up??

DELL-Pupul M · Answer

Okay! So can you confirm this- When you see the device details for the ESXi server, are you able to see the RAC information table? Do you see the RAC IP in that?

If are not able to see the RAC IP in the RAC information table, can a racreset be tried on the RAC?

TRScott · Answer

Nope it can't be seen, and I've tried a racreset on both iDRAC's and I still don't get them to 'merge' and this isn't the first time it's happened, rather frustrating to have to revisit this over and over again.

DELL-Pupul M · Answer

It looks the issue is not on the RAC side but on the server side on how it reads the RAC details. Let m figure out what can be done to fix this issue. Will get back to you soon.

TRScott · Answer

ESXi 5.1 and OMSA 7.4

DELL-Pupul M · Answer

Can you confirm the ESXi and the OMSA version which is there on these servers?

DELL-Pupul M · Answer

Hi,

Can you try running these commands on your ESXi and paste the output here? You can execute these commands remotely on any windows machine and just replace the IP_address with ESXi and replace the credentials.

winrm i SendCmd cimv2/DCIM_OEM_DataAccessModule?__cimnamespace=root/dcim/sysman+InstanceID=DCIM_OEM_DataAccessModule1 @{CommandAndArguments="omacmd=getchildlist showbody=true showobjhead=true recurse=true byobjtype=322 daname=dceda"} -r:https:// :443/wsman -u: -p: -skipCNcheck -skipCAcheck -skipRevocationcheck -a:Basic -encoding:utf-8

winrm i SendCmd cimv2/DCIM_OEM_DataAccessModule?__cimnamespace=root/dcim/sysman+InstanceID=DCIM_OEM_DataAccessModule1 @{CommandAndArguments="omacmd=getchildlist showbody=true showobjhead=true recurse=true byobjtype=320 daname=dceda"} -r:https:// :443/wsman -u: -p: -skipCNcheck -skipCAcheck -skipRevocationcheck -a:Basic -encoding:utf-8

Dell OpenManage Essentials

OME - An Exercise in Frustration

Was this post helpful?