Previous Next

Jack Coates' Blog

Currently Being Moderated

ldms_client 1.7

Posted by Jack Coates on Nov 21, 2008 5:01:32 PM

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.
Tags: ldms_client, inventory_extension, droppedpackets


Nov 21, 2008 8:08 PM EricG EricG    says:

How about some more MAC custom data from Gil Burns, his scripts really fill in holes?  ;-)

 

http://www.droppedpackets.org/macintosh/landesk-mac-inventory-additions/
Nov 21, 2008 9:23 PM Jack Coates Jack Coates    says in response to EricG:

told you my notes were scattered I didn't even look at the Macintosh stuff, and I do have several todo items there. Patrick Gallagher's warranty scraper would be awesome, and I have no idea why I haven't already put LUG and SEC in.

 

The real answer is that I don't often use my Mac*, and OSX doesn't virtualize well. This is an area where someone else could really pick up the slack; there's no need for ldms_client_mac to be in Perl, for instance, as long as it parses that ini file and writes the xml output. If someone more Mac-oriented would like to help, I'm all ears.

 

*I just don't like the UI, sorry.
Jan 29, 2009 5:08 PM addilapi addilapi    says:

This looks like a great tool!  I gave it a try but I already ran into some problems:

 

1.  I would like to find PST files, but most of our users have theirs stored on a D: partition which is not the system drive. Can I modify ldms_client to search this location in addition to the C: drive?

 

2.  My main goal is to gather information on the mapped drives being utilized on our network.  This requires looking at the logged on user's HKCU but the ldms_client GUI only has a spot for 10 keys to be scanned.  We could have as many as 24 mapped drives!  I tried adding an additional line to the INI file but it didn't seem to take:

 

[RegistryReader]
1=Network/C/RemotePath
10=Network/L/RemotePath
11=Network/M/RemotePath
2=Network/D/RemotePath
3=Network/E/RemotePath
4=Network/F/RemotePath
5=Network/G/RemotePath
6=Network/H/RemotePath
7=Network/I/RemotePath
8=Network/J/RemotePath
9=Network/K/RemotePath

 

Is there a way I can get ldms_client to read all possible drive letters?

 

Thanks, I look forward to future updates!
Jan 31, 2009 10:57 AM Jack Coates Jack Coates    says in response to addilapi:

How about another aggressivenes level that tells it to search all currently attached drives? I'll put it on the todo list.

 

Another item that's been on the to-do list for a long time is to allow automatic expansion of the registry keys -- but I think it makes more sense to implement this as a new subroutine which simply checks for all 24 possible drives. Again, I'll put it on the todo list.
Feb 2, 2009 2:15 PM Jack Coates Jack Coates    says in response to addilapi:

I just posted 2.4.1, it'll report user's mapped drives without you having to specify the registry path. http://www.droppedpackets.org/inventory-and-slm/ldms_client

 

I didn't do the "search every drive in sight for email" setting though, gotta admit it kind of scares me. It already takes long enough to find profile sizes...
Feb 4, 2009 7:51 PM addilapi addilapi    says in response to Jack Coates:

Jack,

 

I'm really excited about the changes you've made and I am looking forward to giving them a try but I'm running into some problems.

 

We had to reinstall 8.8 SP2 from scratch after ripping out a failed upgrade from 8.7 SP3 but we managed to save the database and certificates which was everything important.  We haven't yet started to do anything more than inventory our systems.  Since we basically redid the whole server I opted to do a fresh install of ldms_client and that worked fine.  However, when I went back to recreate the package that is where I am now running into problems.

 

I had no problem push installing the package ldms_client_package_2.3.5.exe down to a test machine and making ldms_client work on it when it was the previous release from a few days back.  However, now when I try to do the same thing with ldms_client_node_install.exe I get an error.  This is what I get when attempting to create a new SWD package:

 

"Failed to get the package GUID for \\SERVER\Deploy\ldms_client_node_install.exe"

 

Any thoughts?  All of your help is most appreciated.
Feb 4, 2009 8:32 PM Tim Morris Tim Morris    says in response to addilapi:

I had that same error yesterday until I deployed the package as an EXE instead of a SWD.

Then it worked great.
Mar 11, 2009 9:26 PM addilapi addilapi    says:

So far my experience has been that ldms_client doesn't work with x64.  The latest version appears to report that it is installed fine and I see it in the "Program Files (x86)" but something somewhere is hardcoded to look in the "Program Files" folder which is wrong on an x64 system.

 

Also, I wasn't able to find this information anywhere... how about a method for removing the ldms_client extension from systems where it is not necessary or otherwise undesirable.  In this case a number of x64 servers are generating daily error messages due to the above problem and in general we probably don't need ldms_client on our servers so it would be best to run an uninstall routine for these machines.

 

Thanks, look forward to seeing future updates.
Mar 11, 2009 9:31 PM addilapi addilapi    says:

Oh, hey, how about a feature request while I am at it... any way to gather information on mapped network printers?  It is in HKCU under Printers\Connections but each printer is set up with its own key based on the network printer path making it a slightly different problem than pulling values from known keys.
Mar 11, 2009 10:40 PM Jack Coates Jack Coates    says in response to addilapi:

re x64: I know of some people running it successfully, though I suspect there are some bugs still in there. If you're getting nothing but file not found errors from ldiscn32.exe, did you modify the ldscnhlp.ini? the client installer pafckage does need modification for non-standard platforms, because ldscnhlp.ini can't parse variables. I suppose it's possible to do something in nullsoft, but I haven't gotten that far into it yet. In the meantime, you'll need to roll your own installer.

 

To uninstall, just send a bat file deleting ldms_client.exe, ldms_client_regreader.exe, and restoring a default ldscnhlp.ini (there's one in ldlogon). To be super thorough you might get ldclient/data/ldms_client.dat too.
Mar 25, 2009 4:30 AM Blair Kingsley Blair Kingsley    says in response to Jack Coates:

Hey Jack,

 

Hope all is good with you.....

 

I had a similar problem with the Ldscnhlp.ini file not parsing variables. Presumably you are referring to %ProgramFiles% to work out if it should be Program Files or Program Files(x86) on a 64Bit OS. Pulled my hair out with that one

 

Your current ldscnhlp.ini file looks like the following:

 

[EXECUTE WIN16]

[EXECUTE WIN32]
LAUNCH1=C:\PROGRA~1\LANDesk\LDClient\ldms_client.exe
TIMEOUT1=600

[DATA FILES]
DATA1=C:\PROGRA~1\LANDesk\LDClient\LDCUSTOM.DAT
DATANOPREPEND1=C:\PROGRA~1\LANDesk\LDClient\DATA\LDMS_CLIENT.DAT

 

 

Solution:

Have your inventory collection .exe write to %ProgramFiles%\Whatever......which should take care of where to create the DAT file on a 64Bit OS. Then modify your current master ldscnhlp.ini file to look like the following and see if it works (Did for me):

 

[EXECUTE WIN16]

[EXECUTE WIN32]
LAUNCH1=ldms_client.exe
TIMEOUT1=600

[DATA FILES]
DATA1=LDCUSTOM.DAT
DATANOPREPEND1=/DATA/LDMS_CLIENT.DAT

 

You don't need the full path from root for the executable if it resides in the LDClient folder.

For the data files you also don't need the full path if the DAT file is in LDClient. Mine also go in the Data folder and to avoid the issue with 64Bit OS just put /Data/Whatever.DAT. It doesn't recognise .\ or \ only /

You don't have to worry about program files then.

 

Hope this works for you and helps out.

 

Rgds

Blair Kingsley

NetworkD UK
Mar 25, 2009 6:50 AM Blair Kingsley Blair Kingsley    says in response to Blair Kingsley:

Actually don't use %ProgramFiles% for the ''Where to write DAT file to" variable. Use %LDMS_Local_Dir%

 

Regards

Blair
Mar 25, 2009 8:56 AM Jack Coates Jack Coates    says in response to Blair Kingsley:

Thanks Blair! I actually stopped using ldms_local_dir because one of your engineers wanted to embed ldms_client into ntstacfg.ini and that variable isn't defined until reboot... thanks for the tips on ldscnhlp.ini though, that'll be really helpful. I've got some other stuff going on in ldms_client, might have a new release real soon now with these changes.

Actions

Popular Blog Posts

Incoming Links

LANDesk Community powered by Jive Software's Clearspace ® Subscribe| Legal Notices| Investor Relations| Avocent| Privacy Policy © 2009 LANDesk Software