1 of 1 people found this helpful
I have seen this happen when a system has a LOT of files, we have some systems that run processes that create a ton of data and they time out, and we see this on filer servers, etc.
Run the command below
"C:\Program Files\LANDesk\LDClient\LDISCN32.EXE" /V /F /SYNC /O=C:\inv_servername.scn
Or if 64 bit, it is
"C:\Program Files (86)\LANDesk\LDClient\LDISCN32.EXE" /V /F /SYNC /O=C:\\nv_servername.scn
If this fails, change the path of the output file to a folder the user can write to!
This should succeed, and you can look in the .scn file for folders that contain large amounts of data, if you find any can modify the ldappl3.template file, look for the "ExcludeDir" section, it will have some built in exceptions.
Note, you would only want to do this for "unique" folders that you do not care about, you would not want to exclude most "standard" folders or you will lose access to data you might want inventory on.
After you do this, you need to publish the new template file by following the instructions here:
To see how many affected systems you have add the following columns to your view, "Last Software Scan Date" and "Last Updated by Inventory Server"
The last Software scan will reflect the last FULL scan, the last Inventory scan will reflect the last time the client ATTEMPTED to or successfully sent an inventory scan. If the last 'software' scan date is much older (+3 days or so) than then "inventory" scan I would force a full inventory scan on these devices, see if they sync up, if not, those are likely your troubled systems
Hope this helps
Thanks for the reply James. I've added "Last Updated by Inventory Server" to my column set and I can see that I do indeed have a large number of affected systems. I suspect that I can improve our Inventory success by following your suggestion to exclude certain folders. We have a fairly large "driver library" that is copied to machines during OS imaging. It contains a lot of EXE, DLL and SYS files, and I don't think there's any reason we would need to scan those into inventory.
I still have a problem with one specific laptop model - a Lenovo ThinkPad SL500 which is running Windows XP SP3. The behavior of the LANDesk inventory scanner is a little bit different on this particular machine, and I don't think the problem is related to the number of files. What I'm seeing is that the LANDesk inventory scanner (ldiscn32.exe) just hangs after scanning the hardware, drivers, and software. If I run the scanner from the Start Menu the UI shows a normal scanning process. It happens reasonably quickly, scanning hardware, then drivers, then software. During the software scan the progress bar advances to a certain point (about 90%, or around 40,450 files) and then just stops. The inventory window on the desktop just stays there and never closes unless I go to Task Manager and stop the "ldiscn32.exe" process. When I check the inventory record in LANDesk I can see that the inventory scan was sent successfully, so I don't know what is stopping the process from exiting on the client machine. I have several freshly imaged SL500's here that are all doing the same thing, but I don't see this behavior on other models that are provisioned with the same OS image.
I'll try to do a bit more troubleshooting here, and if I can't get anywhere I'll open a case with LANDesk support. Either way, once we get it fixed I'll post the results here.
Jayson... I have seen similar issues myself... Did you ever get this problem resolved? If so, could you point me to your solution?
Hi Corey. Unfortunately I haven't had time to do a lot of work on the Inventory Scanning problem.
Based on James' reply to my original post (too many files can cause the scanner to time out) we've excluded our Hardware Independent driver library from inventory scans. I'm pretty sure that has helped but I haven't had a chance to verify how much of a difference it makes. (We're a K-12 school district so a large number of our computers are off the network during summer holidays.) I should clarify our problem with scanning the driver library - it's probably specific to our environment and I wouldn't want anyone to conclude that "you should always exclude the driver library". We developed our process for Hardware Independent Imaging before LANDesk introduced HII. One of the troublesome features of our method was that we just copied all drivers for all our supported computer models into a driver library on the target machine. This resulted in a LARGE number of EXE and DLL files that LANDesk's inventory scanner had to look at. Using the current LANDesk HII process you wouldn't be doing it that way - LANDesk HII just copies drivers that are specific to the computer model that you are imaging. We've since switched to the standard LANDesk HII process (slightly modified) so our newly imaged computers shouldn't have the problem with an excessive number of files. (Again, I haven't verified the results since making the change - it's all theory right now. <G>)
We still have the problem with our Lenovo SL500's that I mentioned in an earlier post. I still don't know what is causing it - haven't had a chance to work on it much. We have observed that it seems to be a conflict with the Lenovo power management utility on these laptops. On the SL500, if we install the power management driver and utility, then LANDesk inventory scanner will freeze. If we don't install the power management, then the inventory scanner seems to work fine. Oddly enough we haven't seen the same behavior on other Lenovo laptops which use the same power management utility (but different drivers). Again, we'll probably need to do more testing before we can begin to tackle the problem. I haven't opened a support case with Lenovo or with LANDesk yet - I'd like to make sure I can reproduce the problem and figure out which systems are involved before we take that step.
I hope this is some kind of help to you. If you are observing similar symptoms in your environment maybe "two heads" will arrive at a solution more quickly!
You might try adding a "/debug" to the shortcut that starts inventory and manually start an inventory scan on an affected device.This will not solve your issue, but it will produce a second ldiscn32.log file with more detailed information. You could import this into excel and add a column to calculate how long each step is taking. If one step takes a lot longer than the others, this could be the issue. I once saw a laptop model where the inventory was crashing while detecting a particular security chip. Such things are rare, but the information might point you in the right direction.