1 of 1 people found this helpful
Re Error #1
That's interesting - not seen this before myself. That's something you should open a ticket with support for (though I will point out that we'll check this again 8.7 SP5 and it's possible it's fixed there already).
You will need to provide us with the following - scanfiles that have the problem and a backup of your database. Here's the instructions-template I've got for cases like this:
(1) Always, Always, Always…stop all LANDesk + Intel services. Stop IIS as well on the core server. Take the database offline if possible to ensure that what we are getting is a real backup of the database in a solid, non changing state.
In oracle, the database will need to be open if export is used. If RMAN is used, I believe you should be able to back up the database in a mount state rather than open state. For our purposes, it is much easier to use the export, unless there is specific reason not to.
(2) Make a NEW backup of the database - compress that backup + send it to us. (See below for details)
(3) Launch the 32-bit Console on the Core, and go to CONFIGURE -> SERVICES and then switch to the INVENTORY-tab.
Click on the "ADVANCED SETTINGS" button and find the value for "Store Scans" and set it to "1".
This will store all incoming scan-files (and mini-scans) under:
(4) Reboot the core (easier than restarting all the services)
(5) Ideally, we'd like to have at least 1 days worth of scan-files (in the
\LDMAIN\LDSCAN\SOTRAGE\ folder), the more the better. Collect a few hundred or thousand scans, until the issue is duplicated on your side.
Please note which devicenames HAVE the issue. I.e.: "FX3005" is "healthy" at the stage of the DB backup. After feeding the inventory scans, "FX3005" will display the issue. You don't need to note ALL, just SOME.
(6) Stop the Inventory Service, compress the stored scan-files (the STORAGE directory under LDSCAN mentioned above) into an archive, and send them off to us with the stagnant DB.
Re Error # 2 - the "out of synch"...
... that's actually not "really" an error - it's more a notification.
What happens normally is this:
2.1 - Client collects all the inventory data as part of a scan.
2.2 - it checks when it last sent inventory to the core, and adds that to the inventory scan.
Think of it as "By the way, this is the last time you should've heard from me".
2.3 - The core checks this last scan date against what it has on the database - to make sure that the numbers match up.
If the numbers match up, all is well, and the scan gets processed.
If the numbers do NOT match up, the Core has to assume that a scan-file has been lost "somewhere down the line" - broken connection, network difficulties, aliens - something or other.
In this case, the Core rejects the scan and adds the device to a list of "devices that need to send me a full synchronisation scan". Since the Core missed out "some" data, there's no telling how incorrect the information is that it has, so a full synch scan will be forced next time the device talks to the Core's Inventory service.
It's not really an error, and is "pretty normal" to happen to some degree. It's more of a notification that "a scan-file was lost, and I'm making sure the client's information is correct".
It's not an "error" per se.
LANDesk EMEA Technical Lead.
I'll try to give the support line a call today for the error issue.
As for the "out of sync" issue. It appears that almost every "update" scan thats coming in is being put in the 'errorscan' directory and forcing a full scan on the client. Is there a setting that i can change to have the scans be placed in the database AND have a full scan forced? the reason I would like this is because 1.) the errorscan directory is filling up at an alarming rate. and 2.) LD is regularly used for remote control in my environment and when the scan is being put into the 'errorscan' directory, the database isn't getting updated with the new ip address, at least not until the next inventory scan.
if there's no way to change the setting to have the scans placed into the database AND have a full scan forced then is there a setting i can change to increase the time LANDesk needs before requiring the full scan?
No - no you can't, and you wouldn't want to.
The out-of-synch scan gets rejected BECAUSE data has been missed. So the client + the Core are out of synch. Shoving any information into the Core at such a point would (at best) only give you falsified/missing data, but at worst could have disastrous consequences, hence we err on the side of caution.
Data consistency is a rather important matter :).
If you're faced with a great number of error-scans, what you CAN do is turn off delta-scanning (so that you get full scans sent in) for a while, 'til things calm down. That too is an advanced setting for the inventory service, BUT (and this is a bug but) you will get a LOT more traffic on the network and a lot more data to process (since the average delta-scan is ca. 10 KB and the average scanfile anything between 250 KB - 1 MB).
But if you've got the resources and I/O for it, you can turn off delta scanning.
Furthermore, the database CAN be updated easily with new IP-addresses. All you need to do is to schedule the execution of "miniscan.exe" (you'll find that in the LDCLIENT directory - that create a minute inventory scan file whose sole purpose is to only update network information (these get processed out of turn as well, in priority to "normal" inventory scans).
These automatically get executed when you'll start your computers as is.
LANDesk EMEA Technical Lead.
Wow... I just realized this was still open... I believe the resolution was to upgrade to fix the Error. So I will close this as answered.