ESX 5.1 on a PE R820 not showing in compliance report

Are you referring to this link , or the remote task ?  Not sure I'm following your response. Wouldn't a system running OMSA be able to also discover the iDrac properly? 

• Using Dell Repository Manager with OME Essentials and Dell Management Plug-in for VMware vCenter

So to me there are 2 threads to this issue.  

1. The ESX host does not show in any compliance report, does that mean just because the OS is VMware the compliance report ignores firmware and bios versions ? The context of this would be to just update Dell OMSA, Firmware and BIOS not VMware. 
2. Once a compliance report is available what would be the best practice to update.  

Hi there,

We don't update ESXi via OMSA.  For this situation if you have an iDrac6 or iDrac7, you can discover via WSMan and update that way.

There are some more details in the system update/patch whitepaper on www.delltechcenter.com/ome.

Hope this helps.

Rob

yeah, it's the Update Dell Servers wtih OpenManage Essentials whitepaper.

So we don't patch ESX, you have to do that via the iDrac.

If you are using iDrac 6 or iDrac 7, you have to discover it via WSMan and do the updates that way (out-of-band).

Hope that helps,

Rob

Thanks Rob, I'm discovering the iDRAC's now and I'll post mu results but it would seem to me that OME should be able to link the OMSA device to the DRAC behind the scenes and at the least show basic compliance failures on BIOS and firmware. 

So far I have 240 DRAC's discovered.  

Ok,  It looks like OME discovery DID link these two objects together. :emotion-2:

On My test ESX server I discovered it as a ESX server 1st using the OMSA ws-mad credentials. Then added the DRAC in another expecting  it to show as two devices but it didn't for this server.   

 I can see where both Discovery, Inventory session successfully collected data from OMSA and DRAC but there is only one device with my service tag and it shows in the compliance report ! 

Is there an order of operation you must follow to get this link to work  ?

Ok, Not sure if this a bug or just the nature of how we need to do updates but.... 

Q: Should we NOT discover ESX servers OMSA agent in OME ? 

I have 2 Servers in OME now as a test.  Both are the same make model and VMware build. 

I have an ESX host that I have discovered both as a OMSA supported device (SNMP,WS-man,ICMP) and it's DRAC as a WS-man device. These were 2 discovery sessions that both successfully inventoried the targets.

The other I have only discovered the iDRAC as an ICMP,WS-man) device. 

The server I have discovered both ways is not present in the RAC group but is as a "VMware ESX Server" and it does not give me the option to update via iDRAC. Therefor I cannot update it at all using the root credentials for ws-man. There is no option it change the update method to iDRAC. 

The other is located in the RAC group and does give me the options to update via iDRAC as outlined on page 24 of Update Dell Servers with OpenManage Essentials

I don't think I missed anything in the manuals but it would seem ESX servers should ONLY be discovered via iDRAC to allow agent free iDRAC updates. 

Did I miss a step somewhere in discovery ? 

Right....

So you should only have a single discovery range that only has WSMan enabled to discover your iDrac.  That should do it.  Make sure you don't have an overlapping discovery range.

Thx

Rob

Anyone else on here having trouble updating ESX servers via iDRAC ?

I can't seem to reliably update my R820's even when I just select a BIOS update. 

Considering dropping OME as an update tool and using repository manager to build a simple Firmware,BIOS ISO. 

I would still use OME but strictly for compliance reports and asset management. 

Ok, let me know what problems you are seeing trying to patch your R820 and maybe I can give you some pointers.  

Thanks much,

Rob

Thanks Rob,  

 This is what I have. 

I have discovered the iDRAC and ESX host in separate discovery sessions, host then iDRAC.  The host and iDRAC are on completely different VLAN's and successfully discovered using separate ws-man credentials.  root for esx host and the drac password for iDRAC. 

When I go to manage|Device Search in OME  and search for my target service tag I get one result. Device is available with a green check. 

Then I selected "Advanced Settings" from Manage|System Update|Summary  and set the preferred  update mode to iDRAC.

Logout of the UI then go back to Manage|System Update|Non-Compliant Systems and search for my service tag, one result. 

Uncheck everything but BIOS  Recommended 1.5.0 -> 1.7.2 Package name "R820_BIOS_J9KTW_LN_1.7.1.BIN"  

Select "Apply selected Updates"

Pops up a "System Update Task" window with the expected host and BIOS component listed and delivery mode is iDRAC. I select Run Now, Reboot after update and enter the DRAC credentials. 

The task starts and I see it download the package locally then proceed to step 2 of updating the target system. 

Results:
Starting software update on the target.
The time required for update task to complete may vary depending on the number of packages selected.
If the task status or task progress percentage has not changed for 60 minutes, perform the following actions:
1. Restart the DSM Task Manager Service from Windows Services (Refer to product readme for more details on how to restart the service)
2. Restart the target
3. Re-run the inventory for the target using OpenManage Essentials

So far it never gets past here, I can see the login n the iDRAC logs but not much more. 

Results: Timeout was reached for obtaining the software update status from the target device. Please verify the credentials specified are valid and you can still connect to the device and re-run the inventory to determine if the update was successful. 

Looking for any direction here iDRAC based update simply isn't working. 

I have a 141 Dell ESX servers that need to be maintained and 1600 Dell Linux, Windows hosts.

Any way I can get more verbose errors when running the iDRAC based update ? 

I have found that when I get updates that fail like this that clearing the job queue on the lifecycle controller then doing a soft reset of the drac can help the updates complete.

Here are 12Gen instructions on managing the job queue when logged into the drac via ssh:

racadm jobqueue view -i
       
      

racadm jobqueue delete [-i
      
       ][--all]