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.

Aside from the usual bugfixes and cleanup, this release adds configurable control over how hard ldms_client will look for email folders, and a report of the machine's FQDN.

Code and instructions can be found here: http://www.droppedpackets.org/inventory-and-slm/ldms_client

The conversations around future release ideas for ldms_core have proven interesting and useful, so here's an attempt to gather some of the loose notes:

• TODO -- Firewall status is enabled /disabled. We do this in custom defs, but don’t put the status anywhere.
• TODO -- It would be interesting to see the firewall specifics broken down a bit by port and app, but that could be a ton of work and difficult to format in a useful way.
• TODO -- Capture the connected SSID. Something Perlish? WMI? netsh? All have problems.
• TODO -- Custom vulnerability to install/update Produkey? Is there a better way to use Produkey, or do the same thing without it?
• TODO -- Find a way to identify Adobe licenses... even if it's not decrypted, an identifiable GUID would be useful.
  
• TODO -- Report system crashes from event log.
• TODO -- The ongoing search for greater efficiency.

ldms_client currently stores email information like this:

"Computer"."Email"."PST Files".$name_of_file."File Location" = location

"Computer"."Email"."PST Files".$name_of_file."File Size" = size

"Computer"."Email"."PST Files"."Total File Size" = size.

That makes it easy to do a query for "systems where there is lots of PST file space taken up", which would be something like "Computer"."Email"."PST Files"."Total Disk Size" > 1000 MB.

It is however impossible to query "a list of all PST files and their sizes and locations."

Are there many people who want that sort of a listing? Changing the behavior at this point is likely to break something for existing installs.

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.

There was a bug in the policy reader for 8.8 clients that caused the scanner to fail if no policy had been applied to the client. Download from here: http://www.droppedpackets.org/inventory-and-slm/ldms_client