Here's a useful little tool that aggregates the various logfiles that LANDesk produces: http://www.droppedpackets.org/scripts/ldms_log

You'll find core and client programs, no installer necessary.

I just posted ldms_core 3.4.7, which integrates some of the feedback and discoveries of the last few weeks... thanks for all the help, folks. Debugging help and feature suggestions from LANDesk admins around the world are making this utility into a very useful tool indeed.

Here's a few notes about where it might (or might not) go next:

• Scheduled Tasks
•   
   
  •  
   
  • Check scheduled tasks and policies for RRD stats -- jobs without start times, jobs in success-level buckets, duplicated jobs...   
        
   
  •  
   
  • Delete ghost devices from scheduled tasks (stuck in active because they reported status). If they were from a query they should be deleted from the list, but if they were from a static targeting they should be moved to pending. http://community.landesk.com/support/message/17222#17222   
        
   
  •  
• Import   ldms_delete_users, auto-reassign to single user or delete objects, give the user an option to decide what should be done. Alternatively, rewrite ldms_delete_users as a standalone tool...
• NMAP as an XDD client add-on instead of a core-side piece... this implies some command-channel use and data-passing which are non-trivial, but entirely possible. On the plus side, it will also produce a much higher level of accuracy in OS fingerprinting.
• Email
•   
   
  •  
   
  • Be smart about hysteresis... maybe it could not send another email within a day unless the new email it wants to send is more urgent than the last email that it had to send? Users going from daily runs to hourly runs are having challenges sorting the important emails from the repetitive info.
   
  •  
   
  • Maybe it's email worthy that unmanaged nodes isn't fresh...   
        
   
  •  
• Web pages and reports
•   
   
  •  
   
  • In RRD pages, give textual data supporting the graph. That'll probably push it over the edge to needing templated data instead of straight html.   
        
   
  •  
   
  • Support proxy servers (nice to have for update check, will need for geo-location)   
        
   
  •  
   
  • Give links to non-RFC1918 addresses on maps: GeoIP2Location   
        
   
  •  
   
  • Drill-down from topology map with per subnet listings of computers, including inventory and remote control links for them   
        
   
  •  
• Auto-import email from domain controller into ConsoleUser table. If UserName is like Directory and Email is blank, then import from AD. Requires AD credential input in UI.
  
• Count duplicate serial number records and show a count before the number... e.g. "34 machines with serial number SystemSerialNumb, 2 machines with LYAC12"
• More options, more smarts, more feedback, more efficiency...
  
• Find why McAfee silently stops it from working properly when it's run as a scheduled task (error 0x9 in Windows scheduled task, immediate "success" as a LANDesk scheduled task, works great when run interactively from the start menu).

LANDesk cores are getting more stable all the time, and I'm just not seeing the need to check that everything's working every 10 minutes any more. I've taken the service checking routines from ldms_status and put them into ldms_core 3.1.2 so that it can check and restart services once, when it runs, instead of all the time. I'll leave ldms_status online of course, but I don't see a lot of future for it at this time and will mark it obsolete real soon now.

Here's some roadmap for ldms_core, with discussion of the items:

• It's been 7 days or more since you downloaded content -- I still need to find the best way to filter this. The publishdate column in vulnerabilities is one option, but could false positive. select count(*) from vulnerability where publishdate > getdate()-7; if that value is 0, complain.Maybe even run vaminer.exe instead of just complaining?
• List uninstallable patches? This will probably not be possible, at least without introducing a lot of bugs. XML blobs need to be extracted from the database and parsed, which seems like a lot of work for a little gain.
• More progress indications, for instance after clicking Authorization button in setup. Not exciting.
• Group patches by vendor? Probably not something I can do in this context.
• Topology map. Gateways become nodes, devices sharing gateways are grouped in clouds around them, subnet masks decide size of circle. Core's gateway is in the center and traceroute hops to the other gateways are used to define the map. Use Perl::Graph to generate HTML? This is the one I want to work on next. select defgtwyaddr,count(address) from tcp where nullif(address,'') is not null group by defgtwyaddr
• Kick out a Google Earth file to plot non-RFC1918 addresses on a map. The topology map and this map would both be dumped into the LANDesk reports file share, I suppose.
• Check scheduled tasks and policies for status, alert if lots of jobs have bad status
• Switch to MIME email so I can send multipart messages with attachments, such as those maps. That would also allow reworking of some of the log messages into a table format, using HTML. I prefer the retro look of Text::Table, but it probably can't be displayed properly by the average LANDesk admin's email program.
• The new alerting system might be a better way to look for sync scan issues than using event viewer. If it ain't broke, don't fix it, but it's possible that database lookup would be faster.
• Keep old information and show trend lines on a purty chart, http://search.cpan.org/src/CHARTGRP/Chart-2.4.1/README. This is going to involve storing data and managing time and I'm just not in a big hurry to reinvent that wheel.
• Find a way to detect stuck LPM Event Listeners. Not even sure if this is a database or filesystem issue, but it needs to be found and fixed.
• Convert into a long-running service? Probably not going to happen, I just can't come up with enough justifications to explain why I'd want to go through the hassle.
• Cull Automatically Gathered software definitions with no installations. This is going to be hard, and may not be compatible with the changes planned for LDMS 9.0, but it also would be a lot of bang for console performance. Tempting.

http://www.droppedpackets.org/scripts/ldms_status

I was at a customer Friday, and discovered that when I hovered over ldms_status, it would turn red, flail madly, and keel over dead, sort of like Bowker holding a ball at first and trying to decide what to do with it. Turns out, their server had 1 Inventory Service thread and 4500 clients, so LDSCAN contained a backlog of 4300 inventory scans, and growing. Whenever CountPendingScans ran, ldms_status was correctly deciding to restart the inventory service. It was incorrectly ignoring several instructions to wait a few seconds, and it was incorrectly doing this over and over as long as I hovered over the icon, causing a flickering stream of balloon tips and event viewer messages and doing nothing for the backlog of scans.

Partially, this is a discovery of unexpected behavior from the poorly documented perltray... I'm discovering that the Tooltip subroutine runs repeatedly as long as you're hovering on the icon, and I suspect that it sets the Timer too, overriding my timer settings. But the other part is that I was sloppy about the tooltip in the first place, and was calling code on demand. So, I decoupled the CountPendingScans subroutine from ToolTip. I'd been meaning to do that anyway as a matter of good practice, so finding a bug is just good impetus to do it right.

I found a stupid bug in the service stopping routine when I applied the 5-08 rollup to my core, so this fixes that. I also added a "check for the latest version" routine that I'd been working on anyway.