Integrating Repository Manager and OpenManage Essentials

30 minutes on hold and no one knows where to direct me for OME support. I've been transferred around to 3 different departments. Currently have someone trying to track down what department handles OME support.

you need to speak to the systems management group.  provide a server service tag and then say it is involving open manage. that should take you to the right group.  

They weren't able to identify what is causing this error. I provided them the log file and they're going to have some others take a look at it. In the meantime they suggested simply using OME for pushing out system updates directly to non-compliant servers.

Both of these applications feel like beta to me.

I have the same issue.

RM v1.4.104

OME discovery process has fully completed

OME user is a member of OMEAdmin group

SQL database is remote

OME and RM were both installed using the defaults

So you say that discovery has completed.  Can you just confirm that you have OMSA on the servers and  the servers are classified under the "Server" node and do a quick visual check to see that the hardware inventory has been collected?

Thanks!

Rob

Ok, then it should work.  Looks like I'll need to see if you can call 800-945-3355.  If they can collect logs, etc., it might help the RM team identify the problem.

BTW, we are looking to add first class support for PDU in a future release so it will eventually show up in the device tree.  Not sure of the timeline on that.  If you go to Manage | Alert | Alert Catagories, it looks like we do have some PDU alerts defined.  You might at least get alert support in this release.

Thanks,

Rob

In my case, everything appears correct in OME: Servers listed under "Servers" node with green checkmark, all hardware inventory is displayed, etc.

The only entried in the "Unknown" node are PDUs that were picked up by snmp, and one RAC with the wrong SNMP community string in place.

Marc

I spoke with support and was told, after verifying with an escalation engineer, that OME 1.0 simply doesn't do this yet. 1.0.1 will.

I sent the tech the youtube video showing it in action but have yet to hear back.

Yesterday I received a call from the support rep handling this for me and he also stated that 1.0.1 has this bug, whereas 1.0.0 doesn't. Later today I'll be providing additional debug logs for their engineers to evaluate.

RM 1.4 does have the feature to import from Essentials.  It should function properly (if not please give our support guys a call 800-945-3355)

Repository Manager 1.3 does not have this ability.

Essentials 1.0 and soon to be released 1.01 both have the ability to have repository manager 1.4 look at the essentials database and pull inventory information from that database for the purpose of custom repositories.  

Dcluck -  the import error you see is something we need to look into(but is not related to any other issues i have seen here)  so please get us those debug logs as soon as possible.  

Same app error.

Log error:

InvCompliance.CreateCompliantUpdates: Exception getting compliant updates: Object reference not set to an instance of an object.

Inventory complete.

Local db.

OME: 1.01.1253 clean install

RM: 1.4.104 clean install

Known issues with OME:

Some package updates cannot be downloaded by OME due to bad signatures. (currently ftp.dell.com/.../DRVPK_APP_LX_R316354.BIN and ftp.dell.com/.../FRMW_LX_R310809.BIN) .

There is a new version or Repostiory Manager available below and it may help with some of the issues seen earlier.

ftp://ftp.dell.com/FOLDER00313115M/1/Dell_Repository_Manager_1.4.113.msi

Thanks. The new version does get past the error, but with bad signatures in the catalog, it causes RM to hang after it's done downloading. The only option is to cancel, which then spits out a list of things that it couldn't download due to bad sig, and then deletes the 1.5G of repo that we just downloaded.

These are the package folders for all of the bad sig packages that we need.

FOLDER00196184M

FOLDER00196330M

FOLDER00200176M

FOLDER00200197M

FOLDER00200208M

FOLDER20700M

FOLDER51863M

Note that none of the "FOLDER*" versions that we are needing work, and all the rest with an actual device type directory name do work.

These are all on FTP as lowercase filenames and lowercase directories, even though OME and RM want to uppercase everything. None appear to have *.sign in their BIN directory.  Looks like it was just a bad batch run.

Unfortunately this is still preventing RM and OME from working as designed.

Thanks Chris...yeah, we are providing this feedback to the appropriate folks.

Cheers,

Rob