Table of Contents

Rationale

 

Installation

 

Configuration

 

Execution

 

Customization

 

 

Rationale

In a perfect world, an administrator in charge of a powerful tool like LANDesk would be someone who either had the skills to manage repetitive maintenance tasks, or the time to learn those skills. In the real world, a couple of people devote a quarter of their time to managing a box of surgical lasers, chainsaws, and hydraulic vises. This program is written for you. Its job is to make the LANDesk core take care of itself as much as possible, and to tell you what needs to be dealt with first.

 

Installation

Run the setup program on your core. The Program Files\Monkeynoodle\ldms_core directory will contain the ldms_core.exe binary, an ldms_core.css style sheet, an ldms_core_icon.png graphic, an ldms_core.ico icon file, the NullSoft uninstall program, and a ldms_core_source.zip file containing source code for the program itself, the ActiveState PerlApp compilation instructions, and the NullSoft Installer System compiliation instructions. If you want to work with the source code, this toolchain message might be helpful.

After installation completes, you will be able to launch the configuration dialog, which is what most of this document is about. Once you've made those choices and clicked Ok, a managed script will be created. To finish installation:

1. Find the script "ldms_core" under Managed Scripts in the LANDesk console. Note that you can edit this script if you'd like to select different command line options.
   
2. Right-click the script and select Schedule, which will take you to Scheduled Tasks
3. Drag the Core server into the task to set it as the target.
   
4. Right-click the task and go to properties, then set it to start at a reasonable time and recur at a reasonable rate; please review the Typical Usage section to select your definition of reasonable.

 

Configuration

Start - All Programs - Monkeynoodle - ldms_core - ldms_core setup will launch the database setup dialog:

 

 

Read and write access is required to LANDesk database. If you do not know your database credentials, and you're installing on the core, click the Database button and then click Invoke to recover them. If correct credentials are given, the full setup dialog will be shown when you click Ok (otherwise, you'll be given a chance to try again):

 

Mail Verbosity

The mail verbosity slider controls the severity of a warning that can cause email to be sent. Regardless of whether email is sent, the entire output message will be posted to the ldreports folder as reports\ldms_core\ldms_core-latest.htm. The message severity table is as follows (higher numbers produce more mail):

LEVEL	WARNING
More = 6	Send email for every run (useful for daily reports)
5	Duplicate computers detected (same device name) Dual booting computers detected (same serial number) Duplicate IP addresses detected
4	Manual patch downloads required Superceded vulnerabilities were moved to Do Not Scan Inventory Service settings are not optimal
3	In the last 7 days, less than half of your machines have sent inventory There's an update to ldms_core available The Process Manager event listener hasn't done anything today
2	Vulnerabilities go unpatched for greater than 50 days on average Vuln definitions haven't been downloaded in 7 days Out of the last 24 hours, 10% of your scans caused public key hash errors Out of the last 24 hours, 10% of your delta scans were out of sync
Less = 1	A service had to be restarted 200 or more pending extended device discoveries 200 or more pending alert insertions 200 or more pending scheduler task transfers

The program should not send more than one email in 24 hours, unless the severity of the discovered situation has changed. An example might help clarify this concept: let's say that it emailed you at 9 AM because there were some manual patch downloads required. That's a severity level of 4, so when it runs again at 11 AM and moves some superceded vulnerabilities, it won't email you about it; it'll just log the event and exit quietly. At 1 PM, let's say that it had to restart a service; that's a level 1 alert, which is more important than a level 4, so it sends you an email and restarts the 24 hour wait period. Note that in order to get another email before 1 PM tomorrow, the discovered event will also have to be severity 1. Severity 1 alerts will always cause an email to be sent, no matter how many emails have been sent already today.

If email server authentication is required, fill in the email information and click Authorization. This causes the program to ask your mail server for the types of authentication it supports before showing you this dialog.

 

 Reports are presented in the Management Suite's \\core\ldreports share; you may want to make that a web share as well, if it isn't already. 

Network

ldms_core can use NMAP to perform OS Fingerprinting for Unmanaged Nodes. It will also leverage returned information to fill in missing MAC addresses and equipment manufacturers (per the IEEE OUI database), if necessary. If you do not want to use NMAP for Unmanaged Nodes OS fingerprinting, uncheck the "Use NMAP" box.

If the skip unidentified nodes option is checked, the program will not attempt to re-fingerprint machines that it was able to scan, but was not able to identify.

Serial scanning of unmanaged nodes is rather slow, and can be annoying if you're using the core interactively as it causes DOS boxes to pop up on the screen. Use the "maximum NMAP targets" box to decrease or increase the number of targets that ldms_core will scan in a given run.

ldms_core is also able to generate a network map from the Management Suite database, using the reported gateway addresses. This map is in HTML and you can insert URLs for your routers by filling in the "Network map router URL" field. The value IPADDRESS will be replaced by the real router's IP address. For instance, "https://monitoring/devices/IPADDRESS" will become "https://monitoring/devices/172.15.252.1".

Patches

Patch files are automatically downloaded by LANDesk Patch Manager, but they are never culled; ldms_core evaluates all patches which are no longer needed by detected vulnerabilities (this is the 'all possible patches' value), and deletes them if they exist on the file system and have not been accessed in more than the deletion days value. Patch files on network drives are not tested for access time; they are deleted if there is no longer a client node that needs them. This purge is done in two steps:

1. The database is asked for a list of patches that are not currently required by your managed nodes; these patches are then evaluated for presence and file access time, and potentially deleted. For instance, let us imagine that vulnerability WIRESHARKv1.0.8 was detected and promptly fixed; setup-wireshark-1.0.8.exe is referenced as the patch, and may be deleted when the file access time is older than $deletiondays.
   
2. The files in the patch folder are checked for a database reference; if none exists, the patches are then evaluated for file access time, and potentially deleted. For instance, let us imagine that vulnerability WIRESHARKv1.0.7 used to exist, but is no longer in the database because Wireshark was incremented; since setup-wireshark-1.0.7.exe still exists in your patch directory but is no longer referenced by a vulnerability, it is eligible for deletion when the file access time is older than $deletiondays.
   

Vulnerabilities that have been superceded by other vulnerabilities are moved to the Do Not Scan folder. There is no attempt to manage dependencies in this move; rather I assume that if a patch is superceded, so are its dependencies... otherwise it wouldn't be superceded. A Vulnerability may contain multiple rules, and in some cases a vulnerability may only be partially superceded. A slider in the setup window allows you to specify how superceded vulnerability culling should behave.

Undetected Vulnerabilities are an important concept to understand, and is controlled by the "Should ldms_core clear the scan state of vulns that aren't detected?" check box. By default, a database row is consumed for every vulnerability on every computer; this allows the "Vulnerable vs Scanned" column counts in the Detected window of the Security & Patch Manager. For instance, one might see DENY-GoogleChrome - 50 - 15,000 in Detected when the Type is set to Blocked Apps or All. This would mean that Google Chrome is denied, that it's been blocked on 50 computers, and that 14,950 computers are prepared to block it if the need should arise. Multiply by 25,000 or so possible vulnerabilities, and you can see how the database might have some performance issues.

If you activate the "Should ldms_core clear the scan state of vulns that aren't detected?" option, ldms_core will delete all non-detected scan information from the database. In the above case, that would result in a display of DENY-GoogleChrome - 50 - 50 in Detected, meaning that Google Chrome is denied, that it's been blocked on 50 computers, and that we don't know which other computers are prepared to do the same (though a reasonable conjecture can be formed by querying at the Last Blocked Application Scan Date field).

This option defaults to OFF if your core is version 8.8SP2 or older; it defaults to ON if your core is version 8.8SP3 or better. Furthermore, if it is enabled and your core is version 8.8SP3 or better, it will toggle the DiscardUndetectedBlockedApps and DiscardUndetectedSpyware switches to ON. This means that undetected records of those vulnerability types will be discarded by the vulnerability webservice instead of being stored in the database.

 

Stuck LPM monitoring. If the patch purging feature is enabled, ldms_core will also check that the Automatic Patch Process is still running (if you've enabled it). It does this by looking to the workflow engine's log file and alerting you if there were no events today.

Maintenance

The deletion days value is important: if it is not filled in, your database and/or filesystem will eventually fill up. This is one of the main reasons that ldms_core exists; please do yourself a favor and use it. This value defaults to 30 days.

Tray icon: You can also disable or enable system tray icon usage; if you're not interactively logging into your core server on a regular basis, why spend the resources to show off eye candy? More to the point, there is a known problem with the graphics library I'm using... if you see crashes in GUI.dll, turn off this option. It's not ideal, but there's nothing more I can do.

Reindex the database: If you check this box, ldms_core will perform a soft reindex of all of the LANDesk tables ("soft" meaning that the database is not taken offline, so locked tables won't get reindexed). Arguably this is being taken care of by your DBA's maintenance plan... if you have a DBA, and if he has a maintenance plan, and if it's still working. If that all sounds like Swahili, turn this option on.

Update checking: ldms_core is frequently updated, adding new features and fixing bugs. It will let you know about new versions, but you can reduce the frequency of that update check to keep the annoyance factor down. Also, there's no proxy support yet, so you'll need to disable update checking if your core can't get directly to the Internet.

Setting	Means
Never = 0	disable checking for updates to the ldms_core program
1 - 7, 7 = Weekly	check for an update if it's been more than N days since the last time it checked for an update

If an update is available, you will be notified, but the update will not be automatically installed.

 

Execution

The program first sets up its environment, checks to see if there's an update, and reads information from the registry and filesystem to find out where it's at and what to do.

Setup mode

If it's in setup mode, it will present a GUI and ask for information like database login, email setup, &c. Information that you enter will be stored in the registry (passwords are encrypted using Blowfish). Many of the program's activities involve database reading and writing; the database is opened and closed accordingly. At the end of setup, it will check to see if a LANDesk managed script for running ldms_core exists. If one does not, it will be created, and a suggestion to schedule it will be displayed. If a script cannot be created (because ldms_core is not being run on the core, or potentially because of LANDesk license limitations) then a prompt will be displayed suggesting that you schedule a Windows task.

The Deletion Days Value

If you've set a deletion days number, it will remove unmanaged nodes that have not been seen in longer than that number of days. This does not apply for WAP Discovery nodes, as they're referenced from a second table and need more work to remove.

OS Fingerprinting

If NMAP is present, it will use it to scan unmanaged nodes and try to fill in their OS name, MAC address, NIC manufacturer if those weren't present before. The number of nodes to scan will be limited in order to keep the scan time down. Automated OS fingerprinting is inherently less accurate than, say, personal investigation. Additionally, the technique used by NMAP loses accuracy with greater network distance from the target. The OS Name value is presented with an accuracy percentage value if NMAP is not certain of its return value. If NMAP is able to reach a machine but cannot hazard a guess, that OS Name will be set to "Unidentified" and may be optionally skipped in future scans.

LDMS Statistics

Several statistics are gathered and tabulated. LDMS data points are:

• duplicate device names (multiple records with the same device name).
  
• dual booting or poorly imaged systems (multiple records with the same serial number)
  
• number and percentage of inventory scans this day and week
• number of devices in pending unmanaged client deployment state (most likely failed deployments)
  
• number and percentage of unmanaged node detections this day and week
• number of public key hash errors in the last day (only reported if > 10%)
  
• number of forced full scans in the last day (only reported if > 10%)
• scan insertion errors; these should always be reported, as they are indications that you need to modify your database schema.
• number of successful and failed task status reports this day; this is about machines reporting their status, not the number of tasks or policies concerned
• listing of non-recurring tasks or policies that have not been executed in $deletiondays; these are "stale". and are reported in "User - Task Name - Last Activity" format.
  
• average "unfinished lifetime" of tasks and policies, from scheduled start to successful report
  
• number of users and computers using remote control this day
• number of alert events processed this day
  

The Inventory and Unmanaged scan information is used to create trending graphics, which are presented via HTML and PNG files in LDMAIN\reports\ldms_core. Note that this directory may not be shared by default; I recommend sharing it. Trend information is stored in .RRD files, so rename those if you want to reset your graphs (or back them up if you want to keep your graphs). Note that a limitation in the module I'm using forces the .RRD files to be stored in the current working directory, rather than a specified location. Depending on how you run the program, current working directory is likely to be in one of two places:

• If using a Windows scheduled task or the start menu, look under %ProgramFiles%\Monkeynoodle\ldms_core for the files.
• If using a LANDesk scheduled task, look under %Windir%\system32

Switching back and forth between run methods will cause the displayed data in the graphs to change; try to avoid this, but don't be concerned because your preferred RRD file set will still be there. (In other words, if you usually use a LANDesk task, but you run it from the start menu once and all your data seems to disappear, don't panic -- just run the LANDesk scheduled task again.)

LDSS Statistics

LDSS data points are:

• Number of vulns being scanned for
• Number of detected vulns by severity (you must have defined scopes)
  
• Number of detected vulns by severity which are auto-fix enabled (you must have defined scopes)
• The average unpatched lifetime of all detected vulnerabilities, from detected to repaired
  
• Manual patch downloads that are required by detected vulnerabilities
• Age of the newest vulns... there should be updates every week
  

If any of these values pass troubling thresholds, an email is sent in addition to logging in the Windows Event Viewer.

Data Purging

There are many areas in which LANDesk gathers data, but does not clean it up when it's no longer valid or useful. ldms_core deletes many invalid or out-dated files and records.

IP Addresses: Duplicate IP address records for managed devices are detected and the oldest known-incorrect ones are removed. There are at least two scenarios in which known-incorrect addresses can occur:

1. • Machine A leaves network address 1, by shutting down or suspending.
   • Machine B claims network address 1, reports to core.
   • Core now has two machines with address 1.

2. • Machine A leaves network address 1 by roaming across WAPs or plugging into the wire.
     It claims address 2, but the inventory scan fails to process its update miniscan.
     Machine B takes network address 1, successfully sends in an update scan.
     Core now has two machines with address 1.
     

This feature can be alarming, given that a portion of your nodes will lose their IP addresses; recognize that what you're seeing is an exposure of an uncomfortable reality, not a creation of a new problem. Machine A is no longer at address 1, and keeping a record that it once was there is useless for purposes of remote control and software distribution. ldms_core will only delete one instance of an IP address at a time; this means that the first few runs after installation will show repeats in the duplicate IP address listing. By way of example, imagine that 192.168.10.43 is present in the records of three computers; on the first run of ldms_core, the duplicate address report will show (3) 192.168.010.043 and the oldest instance of 192.168.10.43 will be deleted. The second run of ldms_core will show (2) 192.168.010.043, because there will now be two records with that address; the oldest one will be deleted again. The third run will not list 192.168.10.43 as a duplicate any more, presuming that nothing's changed in the real world.

Patch history: Every security event is recorded, including blocked software executions and failed patch attempts; ldms_core will delete the records that pertain to devices which are no longer managed. This means you will keep all security records for all currently managed devices, but when a device is deleted from the LANDesk database, ldms_core will delete that device's security records as well. Note that LANDesk 8.8 Service Pack 3 adds a hidden setting to delete patch history by date instead of by machine; if that's what you'd rather see, apply that service pack and read its readme.htm for the instructions.

Alert logs: If the core is version 8.8 or better, the new alert system stores logged events in the database; ldms_core marks events which are older than the deletion days value for purging by the alert service. See http://community.landesk.com/support/docs/DOC-5036 for more information. It is possible for the alert service to become confused by orphaned records; if this has happened, it will not purge old alerts or process new alerts. ldms_core will purge alerts that have been marked for purging before it marks new alerts for purging, and restart the alert service if necessary.

Computer Vulnerabilities: When vulnerabilities or computers are moved, introduced, deleted, &c, it is possible for the computervulnerabilities table that maps detection state to specific computers to get out of whack. This is particularly problematic in versions prior to 8.8. ldms_core will delete orphaned rows from this table, improving performance and accuracy.

Failed inventory scans: Error scan files are renamed to indicate the machines that are producing them. Each error scan is opened and searched for a Device Name, Host Name, or IP Address (in that order). If one is found, the file is renamed to _DEVICENAME-OLDFILENAME.SCN. Database lookups of UUIDs are no longer used, for performance reasons. If nothing can be found, nothing is done to the error scan file.

In addition to renaming the scan file, ldms_core will analyze inventory server errors and attempt to determine the computer that caused them. If a more recent scan has not been sent in, the computer's "Scan Type" field will be set to "Outdated" instead of "Full" or "Delta". An example may be in order:

 

In this screen shot from 8/5/09 12:35 PM, TIN and GEODE have both caused inventory service errors in the past 24 hours. Diligently perusing the event viewer and errorscan folder would show that GEODE's error was a simple 2391, Inventory Out of Sync, whereas TIN's is a more serious issue. GEODE's problem will most likely be solved in the short term, but TIN has not successfully scanned in nearly 9 days. A query for "Computer"."Scan Type" = "Outdated" would be an excellent target for an hourly full inventory scan managed task. A query for "Computer"."Scan Type" = "Outdated" AND "Computer"."Last Software Scan" < GetDate()-5 would be an excellent target for an scheduled report or forced agent reinstall.

Stored inventory scans: The Scan Storage directory is searched for files older than the deletion days value, which are compressed into a zip file and deleted. Scan Storage is normally only used during inventory troubleshooting, and administrators often forget to turn it back off, leading to filled disks and crashed cores.

Rolling inventory server logs: The Inventory service can produce a great deal of information in debug mode. Turning on the rolling log and forgetting about it is a fine way to fill a hard drive. ldms_core will delete any rolling log older than seven days and inform you that there is an issue with logging.

Orphaned task members: If the database times out at an inopportune moment, it is possible to get "stuck machines" in your tasks. ldms_core will delete task members that no longer exist in the computers table.

SLM Products: Automatically gathered Software License Monitoring products are tested for installations and then deleted. LANDesk Management Suite will gather product definitions ad infinitum, but it will not delete them. ldms_core finds products with no installations (the product is not installed on any managed computer). It then deletes the file and product definitons for that product. Note that this will not happen if the product is in a compliance group, because these products may have licensing information associated with them. Each run of ldms_core is limited to acting on 250 software definitions, for performance reasons; repeated runs will eventually clean out all unnecessary product definitions.

 

Network Mapping

If a network map is requested via command line (the default behavior), each gateway in the database will be tracerouted and an HTML map will be generated. The map is color coded as follows:

Links	Gateways
a white line means the gateway is less than 15 hops away	a grey gateway has less than 10% of your nodes behind it
a yellow line means the gateway is 15 or more hops away	a pink gateway has between 10% and 25% of your nodes behind it
a red line means the gateway is unreachable (a metric of 31 is assigned so that automated graph generation will behave sensibly)	a yellow gateway has between 25% and 50% of your nodes behind it
	a blue gateway has between 50% and 75% of your nodes behind it
	a green gateway has more than 75% of your nodes behind it

 

Health Checking

Queue checks: The alert queue, the scheduler queue, the inventory queue, and the extended device discovery queue are all checked for excessive load. If there are greater than 200 files in any of them, an alert message will be recorded in the event viewer and sent via email. If the inventory queue is backed up, the LANDesk Inventory Service will be restarted in case it has hung.

Service checks: The LANDesk services are checked for running state and then restarted if necessary. Each possible service is first tested to see if its startup type is set to Automatic; set it to Manual if you turned it off on purpose and don't want it tested. If a service is found not to be running, a single start command is sent; status is checked again, and an appropriate email message is sent.

Event checks:  The Windows event viewer is checked for forced full scans, public key hash errors, and schema errors. Any schema error requires administrator attention and will cause an email alert, but forced full scans and hash errors will only trigger an alert if they've occurred on more than 10% of the managed nodes in the last 24 hours.

Server configuration checks: The core's boot.ini is checked for optimal configuration, per the LANDesk server BKM.

ldms_core's activity is logged to the Windows Event Viewer, and potentially mailed. If an email should be sent but cannot be, a time-stamped log file will be written to the hard drive in the current working directory. Look for ldms_core.exe-$datetime.log

 

Typical usage

Recommended usage is to create a LANDesk scheduled task to run at least once every 24 hours. More frequent runs will mean more resource utilization, but more granular data gathering. If you run it nightly, you'll have lower impact on resources and lower success rates with OS fingerprinting. If you run it daily, the converse is true. If runs are less frequent than daily, your RRD trend graphics will present an unreadable set of single-pixel dots instead of attractive and stylish trend lines.

Be aware that the RRD files are stored in current working directory, which depends on how the recurring task is run. For instance, Windows Scheduled Tasks and manual runs will use %PROGRAMFILES%\Monkeynoodle\ldms_core, but a LANDesk Scheduled Task will use %WINDIR%\system32. If you switch from one to the other, you can copy the RRD files from the other one so that you don't lose historical data.

The system tray icon is a nice indicator of progress, but it can also be a problem for scheduled tasks. If your task exits without doing anything, or if ldms_core crashes with an error in GDI.DLL, turn the system tray icon off.

Customization

The %ProgramFiles%\LANDesk\ManagementSuite\reports\ldms_core directory will contain automatically generated .html files and .png files; to customize your report appearance, modify the ldms_core.css and ldms_core-icon.png files in that folder.

Command-line switches

ldms_core does not require command line configuration -- run the setup mode by clicking Start > Programs > Monkeynoodle > ldms_core > ldms_core setup to make your configuration choices, which will be saved into the registry under HKLM/Software/Monkeynoodle/ldms_core. To access the accurate options for the version of ldms_core you're using, type ldms_core.exe /help

in a command window.

 

/help	Use /help to display the applicable command line options. -h or --help would also work.
/debug	Use /debug to specify debug mode, which increases the verbosity of logging and prevents file system modifications. All logs, debug or otherwise, are written to the Windows Event Viewer. Additionally, debug causes a logfile to be written into your current working directory. -d or --debug would also work.
/map	Use -map to make ldms_core generate a network map. -m or --map would also work. This is switched on by default in the automatically created LANDesk Managed Script.
/setup	Use -setup to initiate graphical setup mode. -s or --setup would also work.