We are a Dell shop. We're using Dell Command|Configure to access the BIOS information from within Windows. Dell CC can spit out a .ini file listing the characteristics, one per line, like "sysname=OptiPlex 7020". I would like to include these in each machine's inventory. I've tried the following approaches, but haven't gotten any results to show up in the Inventory of a machine that I know has the file.
How to read content of INI files on clients into the inventory scan
How to Include Contents of LDAPPL3.INI in inventory
Gather INI information via inventory
It would be very helpful, especially as we're trying to implement a directive to add a BIOS password to every machine, if we could pull this .ini file into Inventory in a way that we could then query on the results. What's the best way to do this?
We should already capture BIOS Board Name in the Inventory for devices in Computer.System.Board Name
Here's an example of the information in this .ini file that I know we've used in previous situations, or which I can easily imagine a use for in the near future (there may be others):
The ability to manipulate the BIOS from within Windows, and especially remotely and en masse, is a powerful tool. I'd just like to put that power and LDMS together. It sounds like the best way for me to do this is to write a batch file or script that takes each of these name=property pairs and puts them into the registry, where LDMS can pick them up? Or is there some way for LDMS to read a text file when it goes to perform a task, and then vary what the task does based on what's in that text file?
I believe if you install OMCI then our system can pull BIOS infor using the LDDellOMCI.exe that is in your LDLOGON folder on the core. But your one doc is out of date try this one for Cfgfiles: How to Include Contents of LDAPPL3.INI in inventory
Depending on what you're after - if it's just a few data points, you could grab those via some script & throw it at the registry & pick it up via -- Issue: Custom Data Registry Scan Not Working: How To Pull Registry Information Using The Manage Software List -- for instance too .
Is OMCI (now known by Dell as Command|Monitor) still supported by LDMS/EPM? I'm not finding reference to it in the Users Guide, or in any documentation newer than that.
It's just a "binary that you run to do stuff" ... not entirely sure what there would be to support / not support?
"execute the thing with command line options as desired" ... it's just a remote execute...?
Or am I missing the forest for the trees here?
Joe said, "if you install OMCI then our system can pull BIOS info using the LDDellOMCI.exe that is in your LDLOGON folder on the core." I can see the LDDellOMCI.exe throwing an error when a system is booting up, but I don't know how LDMS "can pull BIOS info using the LDDellOMCI.exe". That's what I mean by support or not support. I'm going through iterations of support techs trying to get LDMS to pull a WMI query, but it seems one has to do it Just So for it to work, and so far, I'm not doing it Just So, even with their guidance. I had hoped that the use/support of LDDellOMCI would mean that the several fields within WMI or wherever would just be pulled into LDMS Inventory for a system without manually creating the query for it.
I'm pretty sure that DellOMCI is a command-line tool.
If it is, the idea is that you use it (i.e. - run it) and grab the output & throw it into a place you want (registry, INI file or whatnot) to pick it up from. So it's just a case of "running a script / executing a thing remotely" that'll give you (hopefully) the data you're after.
So it's not really a question of supporting it. It's just "run the thing" and "develop & test / hope that it'll give you the output you need".
So - hypothetically - you could have something like the following pseudo code/script...
#1 Initialise / start logging #2 Run the command & capture output. Capture errors separately. #3 Format the output into something sensible & save it into a desired location. #4 Handle / notify of any errors. #5 summon cup of coffee.
... granted, #5 is optional, but essentially the above is roughly how I'd imagine this to work. The nice thing is that you can "do the deed" via a custom definition via vulscan, or via software distribution ... ... or a local scheduler task ... however you want/need it to .
<I tend to claim / say that there's usually AT LEAST 3 different ways of acheiving the exact same thing in EPM ... just down to personal flavour >