ldms_client 2.4.9 hits the web today. This is a major revision, because it moves the inventory locations of several attributes, and it provides an optional ability to model data for those attributes. The affected inventory items are Battery, NetStat, Mapped Drives, and User Profile Size.

What does that mean? From the manual:

A database schema is the map of the database; it's how programs know where to read and write data from. LANDesk's database has an extremely clever trick available to it, which allows it to extend that map on the fly. If you send it data that it doesn't know how to map, it will figure out what you wanted and make it happen. For instance, if you add "Foo"."Bar" = "Baz" to an inventory scan, it will reason that you must want to assign Baz to a value named Bar, which is under an object named Foo. So it takes the data, puts together a attribute relationship, and stores it all in the UNMODELEDDATA tables.

By default, much of the data that ldms_client provides is unmodeled... after all, if it were modeled that would mean that LDMS was already gathering it, and ldms_client wouldn't need to. If you just need ldms_client temporarily, this is fine. For example, if you're just trying to quickly ascertain license compliance or force Dell WoL into a known state, you probably don't want to make a permanent change to your database.

On the other hand, performance of unmodeled data is potentially very poor, especially as the number of nodes reporting it goes up. That means that if you're using some of ldms_client's features as a permanent part of your inventory, you'll want to model the data.

This is still optional because it's potentially risky, but the benefits are worth pursuing.

Every now and then someone will question the support terms of one of my open source projects, such as ldms_client. (To refresh those terms, they are: email me and I'll see if there's something I can do when I've got time to work on it.) Users who are unhappy with such terms will occasionally then go to the trouble of implementing their own custom solution to their inventory extension problem.

Chances are good that such a solution will not be supported either. Bearing in mind that I don't work in LANDesk support and am only guessing at what a given engineer will do on the day you call for help, my opinion is that LANDesk's support will center around successfully running the command and transferring the data.

ldms_client uses supported methods to do that, and so do the vast majority of the homegrown scripts that I've seen. But if either your script or ldms_client quit working properly, LANDesk support is within their rights to quit troubleshooting when they determine that LDMS can still execute programs and upload custom data. If the framework is working but your AV client is blocking your VBscript from copying a value out of HKCU into HKLM so that LDAPPL3.INI can pick it up, that's not really LANDesk's problem.

ldms_client exists because someday you'll come across another need for some goofy inventory extension, and someday they'll quit asking for this one... When you start trying to turn extensions on and off without its framework, you'll probably wish you had it.

So, this morning I got an .exe email attachment sent to me, which Outlook 2003 (more or less wisely) refuses to download. Don't get me started on the primitive model that says a dot and three characters are enough to identify naughtyware... but rather than ask my associate to rename the file and send it again, I decided to find where Outlook configures this. Google, STFW, and there we go: http://www.msfn.org/board/lofiversion/index.php/t16098.html

That key is reverse logic, you're defining what to allow, not what to block... so I created a STRING and put .exe in it, restarted Outlook and downloaded my file. Then, I went to Start > Programs > Monkeynoodle > configure ldms_client and added the string to my HKCU registry reader... if anyone's messing with this, I want to know.  A LANDesk Query against Custom Data - HKCU - Software/Microsoft/Office/11.0/Outlook/Security - Level1Remove will do quite nicely.

ldms_client version 1.2 is posted. HKCU reading works now, and it turns out I did need to use a wrapper program (REGEDIT.EXE /E and REG.EXE QUERY both behaved strangely for my needs). This inflates the size of the client install, but compromises must be made from time to time.

Version 1.2 also reads the Machine SID, and fixes a bug in version detection introduced by some of the post 8.8 patches.

With this release, my planned feature list is all done for Windows clients, until someone suggests some more features. Failing that, I'll be working on a Mac client next.

http://www.droppedpackets.org/inventory-and-slm/ldms_client/

This is a centrally managed client inventory extension tool... it gathers a bunch of information that the base LDMS client doesn't. Currently, that means battery, netstat, nic duplex, landesk policy status from the client's perspective, PST file sizes, broker configuration mode, and the domain members of local groups. Here's a screenshot of the administration tool:

In the future, it will also include a startasuser.exe-powered HKCU key fetcher. I'm also thinking of produkey support and OSX support.