Looks like the issue here is going to be the time difference between ldapplpcgi.sig and ldapplpcgi.exe. According to that document they both have to be the same. Of course the patch mentioned on the doc is old but maybe support can provide you with the set of files that have matching dates. Do you have another core or dev core that you can copy them from?

We have come across some of these systems that refuse to update, and in most cases if you delete the files (ldappl3*.*) in the ldclient\data folder and call an full inventory scan, they will usually download the new files.

We created a batch file that we can push out to these using a Custom Def.

We have come across some of these systems that refuse to update, and in most cases if you delete the files (ldappl3*.*) in the ldclient\data folder and call an full inventory scan, they will usually download the new files.

We created a batch file that we can push out to these using a Custom Def.

Created a CD as suggested, however just tweaked it a little. I just included a script to delete the files, rather than having to worry about downloading a patch, just in case there are some other issues.

And here's the script. It detects both 32bit and 64bit, and will only delete the files that contain "ldappl3" in the file name.

The "strInvCmd" variable is just declared before the command to delete. I guess "proper" coding would put it next to the command "ReturnCode = wshShell.Run(strInvCmd)" where the actual inventory scan command is called.