What is your version and SP level? What OS is your client? I would say generally delete or rename the LDAPPL3.base file in ldlogon and use the Make Available again. Verify that the ldappl3 files are updated and look inside the ldappl3.INI in the ldlogon to verify that the new reg keys are there. Then on the client modify the Program Files Scanner line and add a /F /SYNC and run it. Then check the files on the client again.
Verify that the agent configuration you deploy actually did have the default setting to automatically update the LDAPPL3.INI file. Another possibility is that the client file has been made read only for some reason.
We just went to 8.8 two weeks ago and the custom registry keys were being scanned successfully until last week. All the client PCs are Windows XP, SP2 with the latest patches. I have not updated the clientse to 8.8 yet as we have an outstanding issue with support in regards to softmon.exe so the majority of the clients are at 8.7 SP4.
I have tried renaming the ladppl3.base file and making it available. When I force sync a scan on a local PC the new ldappl3.ini gets created and it does have the custom registry keys in it but they still are not reporting back to the database.
There is a command line switch, /i=http://CoreName/ldlogon/ldappl3.ldz. This is the switch that tells the client to download the updated ldappl3 file. Without the switch the clients may run the inventory scanner but they won't get an updated ldappl3 file. Check to make sure this is in the command line that you're running (if you are running a script).
The agent configuration has a setting to have the clients use this switch, the default is to include it. If you check under the inventory scanning, it says 'automatically update ldappl3 file'. If you uncheck this then the clients won't automatically check for a new file and you would have to manually update them all. This might be the root cause of the problem.
So if the files is on the client and it has the reg keys in it, and you are running a Forced Full scan and they are not in the DB.
1. Is the last Software Scan date getting updated to current? (if not then the scans are most likely in the errorscan directory and this is related to old agents.
2. If you do a full scan to an output file and then manually place that into he ldscan directory on the core do you see an updated last software scan date?
3. If the last software scan date is consistent with the forced scan date, then I would say the reg key entries have some sort of an issue and you should post them here.
Maybe turn on the "store scans" option on, at the core server (Inventor Serrvice | Advanced Options) for a short period of time, force a scan and then verify the contents of the inventory scan file. Could be a syntax error in the LDAPPL3.Template maybe? Alternativly, do an offline inventory scan with the /o option to examine the inventory scan file locally?
I came through a similar case with a customer.
We were trying to collect HKCU keys on the registry. They don't get collected unless the LDISCN32.exe is run as the current user.
The solution is to use STARTASUSER.exe utility in order to get LDISCN32.exe to run as the current logged user and bring those HKCU keys.
STARTASUSER.exe is on the C:\Program Files\LANDesk\ManagementSuite\LDLogon folder.
You can copy this file to the C:\Windows\System32 folder on the managed devices in order to be able to run it from any folder (as I did) witha custom transfer file script.
Then, call it via a custom script:
REMEXEC01=cmd /c startasuser.exe <qt/>%LDCLIENTDIR%\LDISCN32.EXE<qt/> /NTT=CORESERVER:5007 /S=CORESERVER /I=HTTP://CORESERVER/ldlogon/ldappl3.ldz /F /Sync
It should now bring any HKCU registry key you are trying to get, along with any HKLM keys.
Don't forget to edit the LDAPPL3.Template file to fix the registry keys to be collected and then updating it through the "Make Available to Clients" button on the Software License Monitoring Module. This will re-create the LDAPPL3.INI file and it will be updated on the managed devices on the next or scheduled inventory or via the previous script.
I agree, but since this customer wants to keep his LDMS install as "pure" as possible, adding ldms_client tool was not an option; even though, I have to say I feel it more powerfull and more "automatic".