Description

It is often beneficial to gather various registry keys from clients and put that information in the LANDesk database. Getting this process to work can be tricky at times. The information below outlines the process and what to check for at each step of the way. This process assumes the issue isn't found at each step of the process.

Source article:How to scan for custom registry information using LANDesk

Resolution

After configuring the registry key according to the source article above you must trace every step of the way for a particular machine to see where the problem is. The process is outlined below.

Step 1: Make sure you are running a full sync inventory scan. There are many ways of doing this but here is one article to help: How to create a script to force the client to run a full inventory scan.

Step 2: Ldappl3.ini file on the core. After configuring the key it gets placed in both the database and a file called ldappl3.ini. Once the information is in this file it gets propagated to all clients. This is done when an inventory scan is performed and the scanner checks with the core to make sure it has the most up to date version of the file. Check this file and compare the new entry with existing working entries (several are pre-configured)

Location: C:\Program Files\LANDesk\ManagementSuite\LDLogon

See the highlighted section below. This is the configuration when it's added to the ldappl3.ini file. As mentioned later in this article comparing this against the other keys shown here (which are default) may help in determining the problem. Any extra spaces, commas, etc will cause the scanner to skip the registry key.

Step 3: Check the ldappl3.ini file on the client.

Location: C:\Program Files (x86)\LANDesk\LDClient\Data

Step 4: Does the data exist on the client? Check the registry on the test client to be SURE the data is there and in the configured location. Don't assume here...many times this is the source of the problem during testing.

Step 5: Create an output scan on the client.

Article: Creating an output scan (Note: This is for support but the procedure will work here too)

If the data isn't in the output scan then there is a problem on the client that needs to be resolved. Look closely at the ldappl3.ini file. Any extra spaces, commas, etc will cause the scanner to skip the request completely. Comparing it against working keys is critical here. Also, certain keys (like HKCU) may not be gathered on clients. By default, a scheduled scan will launch as the "localsystem" account and not a test or domain user that may be logged in and running the scan manually.

Step 6: Assuming the data is located in the output scan check the core "Unknown Items".

Article: Custom Data is not being inserted into the database.

By now the data should be listed in the target location specified in the initial configuration. If it is not...perhaps try another more simple location. The default is Custom Data and extra sub-folders can be created under this category.