This problem is exacerbated by OME's inability to always detect if an update failed. f2000sa mentioned a case in which the DUP contains the wrong version. I encountered an instance today in which I asked OME to install Network_Driver_GPJ8K_WN_18.2.2_17.8c.4.3. Everything appeared to work well, with the OME log reporting:
[09/14/14 09:40:20] Vendor Software Return Code: 0[09/14/14 09:40:20] Name of Exit Code: SUCCESS[09/14/14 09:40:20] Exit Code set to: 0 (0x0)[09/14/14 09:40:20] Result: SUCCESS[09/14/14 09:40:20] Name of Exit Code: SUCCESS
But, when I manually ran the DUP on the system, it was clear that it hadn't actually installed when OME tried it. (It did install fine when I ran it manually.) The lesson is that you need to stop trusting your DUPs. I had previously recommended that you get with the OMSA team and ask them to provide some way for you to manually initiate an inventory collection. I think this function is needed, not only to update the OME status, but to actually validate installation success. At the end of an update task, you should kick off an inventory collection, then use it to validate all of the DUPs that reported success. If you don't find the system reporting the new version, then you should fail the update and put a note in the log that the update appeared to succeed, but validation failed.
And I think Dell should consider dogfooding OME. That way, this type of feedback will come from internal sources instead of your customers. In my opinion, OME is currently unusable for installing updates and this leads me to conclude that no one within Dell is trying to use it to manage production systems.
I agree and stopped using OME for updates a while back.
I only use it for alerting and data at this point.
When running updates there is no real time feedback in OME on the actual status of what is happening. When I run updates in the OS using .BIN files I am able to get feedback on the progress and I can immediately see if the update is stuck or has completed etc which allows me to do something right away if there is a problem.
I work on systems that can only be out of production pools for very small maintenance windows so every minute counts!!!
I was hoping OME 2.0 would have better up to the second reporting on what is happening with updates but still just a progress bar that is "sometimes" accurate.
Updates though OME is really best suited for corporate environments where people go home at 5. Sadly the internet doesn't work that way :)
i had the same issue. this may not address your issue directly, but this is what i did.
load an old catalog, then the latest catalog. depending on how big your network is, mine took about 5-10 minutes.
hope this helps.
I'm just starting to use OME now and we thought this was just what we were looking for as we want to get all our systems up to date with the various Firmware items that are out there. However, I have the same problem mentioned here.
In install updates, let the server reboot, go back in and the same updates are listed. I wait all weekend and no change. I manually run the Inventory on the system and no change. I remote into the system and restart all the DSM services and no change.
This is horrible.
Is there a specific, 100% guaranteed to work method of getting OME to properly detect what version of things is actually installed on a system? Our systems haven't been updated in a really long time so most have 10+ things that need to be updated and this is going to be a nightmare if I can't accurately tell what's been updated and what hasn't. *sigh*
If the SUU method is more accurate, can I use OME to tell what's needed and then use the SUU to apply the updates? Is it better to just use the SUU and tell ti to do everything and it will just only do what's needed? This would be fine for the servers located here but we have many in remote locations as well which that won't work for.
Also, does anyone else have trouble with Power Supply Updates? I have one that won't install no matter what I do. I spoke with someone from Dell and was just told to ignore it. Problem is that then all my systems show up as non-Compliant in OME which doesn't help...
Here's how I've been using OME and maintaining my sanity.
1. Go to Manage > System Update > Non-compliant Systems
2. Use the "Select All" check box to select all systems for update.
3. Sort the bottom list by "Package Name".
4. If you have a lot of systems that are the same model, there will be a lot of duplicates. Once for each distinct package, right-click and select "Details for <package name>" from the popup menu. This will open a web page to download the package.
5. Download each distinct package and save them in a network share.
6. RDP to each system and manually run the appropriate updates. This will provide positive confirmation if an update succeeds or a useful error message if it fails.
7. Don't worry about OME. _Eventually_ it will notice the updates were installed.
actually this is partly correct.
I am performing the same steps but i have to note that:
1.This way the tool is not anymore automation orientated.
2.If i don't delete the Devices and re run inventory they will never show up with a new status.
Both of the above make no sense to continue using OME for the reason it's been built.
I think you were just lucky with the last step. I tried the step earlier in the process, with no avail... This problem is still a problem! It's 2017. What is a relyable workaround Dell?
For OME to pick up the installed versions you need to have CSIOR enabled in the iDRAC.
Collect System Inventory on Restart (CSIOR): CSIOR is a Lifecycle Controller feature which allows collecting system inventory and stores in common storage space. CSIOR can be enabled by clicking Hardware Configuration -> Hardware Inventory in Lifecycle Controller.
If it is still not working please post information about your environment:
Hello Martijn, Thanks for responding so quick.
I can't seem to find the setting you are talking about in the iDRAC nor OMSA webinterfaces.
Since last month we are trying to get back on track with all the firmware updates. As a test, we upgrade our ~45 servers in groups of 8. They are all PowerEdge Rack servers; R610, R620, R630, R710, R720 R720xd. They are all running Windows 2008 R2 or higher. We've added discovery ranges which include the Windows IP adres, but exclude the iDRAC IP adres. We'd like to keep deploying all updates In-Band.
Just tested: Deleting the device from OpenManage Essentials and using the "Discovery range - Perform Discovery and Inventory Now" works. The device is now reflecting the correct current firmwares needed.
Of course i have many servers with this issue; Under Manage - Devices - Details tab it does reflect the correct firmware information like BIOS, but at Mange - SystemUpdate it does not.
Where possible I would advise to do Out-of-Band updates (12G and 13G)
OME only supports the following firmware versions if you look in the Support Matrix, so that is most likely your issue.
For Dell’s 12th and 13th generation of PowerEdge servers — 18.104.22.168 or later
For 11th generation of PowerEdge servers — 1.6.x or later
For PowerEdge M1000e — 5.1 or later
For PowerEdge VRTX — 2.1 or later
For PowerEdge FX2 and FX2s — 1.3 or later
For monolithic systems — 1.98 or later
For modular systems — 3.65 or later
22.214.171.124, 126.96.36.199P10 and 188.8.131.52
We stopped using OME to push update because it was too unreliable and a pain in the *** to use. Instead, we use Repository Manager to pull down the available drives and things for the server models we have and then just run the ISO on each server.
It's a bit more work but it has never given us any problems.
I've come to peace with OME. I install the updates and then check it a few days later. It usually figures out things have changed by then. Then I install more updates. If there is a particular update that fails to install multiple times, I download it and manually install it. This usually takes 1-2 weeks.
Yes, I hope one day that OME will be smart enough to know updates have been installed that it installed itself. But, this is better, for me, than the pre-OME days of having to download the server update utility ISO, distribute over slow T1 lines to a dozen servers and then manually run it on each server.
I'm confused, i thought In-Band (through OMSA) was the way to go and supported all the types of updates. I thought Out-of-Band (Through iDRAC/Lifecycle controller) was only able to the firmware updates.
Also with in-band the server stays online while updating untill the reboot is triggered. Downtime is about 10 minutes per server. With Out-of-Band the server will be offline for an hour updating firmwares..? Right?
The documentation is not clear. You need to reboot the server and press F10 - Enter the Lifecycle Controller. This is where you will find the collect inventory on boot option.
Firmware updates from OME to a server through the DRAC (Out of Band) will only take the server down for the reboot BUT just as any firmware updates they will be applied during the boot in the lifecycle controller so the boot will take longer than a normal reboot. What OME does is send the updates to the DRAC and they get applied immediately if no reboot is required or they get added to the lifecycle queue if a reboot is required.
I find that when I do BIOS, PERC and NIC through OOB it adds about 10 minutes to the reboot on 12Gen and 13Gen servers.