There are many different reasons why Inventory is not processed, updated or duplicated. This article will address the most common ones.
|Verify the Processing of Inventory Scans|
The inventory scan is copied from the client machine to the following folder on the LANDesk Management Suite Core server:
(Drive the Core is installed on):\Program Files (x86)\LANDesk\ManagementSuite\ldscan
Check 1 - Check the Last Updated by Inventory Server Scan field
If you have machines already listed in your "All Devices" section, but you feel that they are not updated, please check The Last Updated by Inventory Server. This date indicates the device sent a scan to the core. Note that if the devices scan is rejected, the The Last Updated by Inventory Server will update but the Last Hardware Scan Date will not. Its helpful to look at both of these to determine if the device has even attempted a scan and if so did its hardware scan process.
Check 2 - Check to see if the Inventory Service is shut down
Open up your Windows Services on your core and check to see if the Landesk Inventory Server Service is running. If it is not, start it. Inventory should now start processing. To find out reasons why the inventory service stopped, review Checks 3-6.
Check 3 - The LDSCAN folder
As scans arrive they will be visible in the ldscan folder. Once they are processed by the Inventory Service they will be deleted.
3.1 - If there are a large number of SCN files in the ldscan folder, but you can see that they are being processed (i.e. they get deleted) this would indicate a) That the server hardware is underpowered or not dedicated to LDMS or b) that a lot of inventory scans are being sent at the around same time (i.e. at 9:00 am) due to a poor choice of agent configuration. This is not really a problem, but is indicative of a poorly designed or administered server configuration.
If your core supports Multithreading, you can try raising the DB Threads value to increase inventory processing times. Reference this document: About DB Thread Configurations
*Note - If you turn the DB Threads value too high, you might start seeing deadlock errors. Reference this document for more information: Issue: Database exception errors - Deadlocks
3.2 - If there are a very large number of SCN files in the ldscan folder and the queue is getting longer. Scans are not being processed. This is a problem, and indicates that the inventory service on the server is no longer running. This can be caused by one of the following:
- a) A failure to reactivate the core server license (LDMS requires regular reactivation over the internet. If the license cannot be reactivated the inventory service will no longer start.
- b) The Landesk inventory service has shut itself down because it received a large number of invalid scans in a predefined amount of time. This is a safety mechanism designed to prevent database corruption. In Program Files (x86)\LANDesk\ManagementSuite\ldscan folder there are 3folders. ErrorBigScan, ErrorScan, and ErrorTrans. By default if more than 10 bad scans go into these three folders in a 24 hour period then the inventory service will stop.
*Note - The presence of a small number of TMP files in the ldscan folder is not indicative of a problem.
3.3 - If there are no scan files in the LDscan folder, We need to request a new scan to test with. Please choose 1 machine listed in your core, and request a full sync scan. Note if it states successful or not. I also like to try and initiate a scan from the client machine as well to see if it succeeds. and updates the "Last Updated by Inventory field" If you would like to get an output scan from the client and manually drop the scn file into the ldscan folder on the core for testing purposes, please reference this document: http://community.landesk.com/support/docs/DOC-28508
If the inventory gets removed from the ldscan folder, but the inventory doesn't get updated, Proceed to Checks 4-6.
Check 4 - ErrorBigScan folder
This folder should always be empty. Scan files that exceed a certain maximum size will not be processed by the inventory service. They will be moved to the ErrorBigScan folder and will be ignored. This is a safety mechanism to prevent database corruption If you find any scan files in ErrorBigScan then this indicates a configuration problem and inventory will possibly be incomplete. The scan files can be examined in a text editor, such as notepad, to try and determine which devices are generating them. If the number of scan file is small, then move on to the next check.
If the scans go into this folder, that means that the scans are too large and you must change the default maximum scan file by going to Configure-> Services -> Inventory ->Advanced Settings-> Max Scan File Size
*Note - File size is listed in bytes. Default is 10,000,000 which is 10MB. Change that to 30,000,000 (30MB). It will also prompt you to restart the Inventory Service.
Check 5 - ErrorTrans
This folder should always be empty. If any scan files are found in this folder it indicates that scan files are being corrupted. This could indicate either a network problem or a serious agent configuration problem. The corruption usually would be corruption of Metadata. This occurs when a scan is returned from a client as either a corrupt scan or mal-formatted to the point that it causes the Inventory Server Service to model that invalid data on the fly and insert the bad data as objects in the Metadata tables. It is most notable when performing queries within the LANDesk Management Suite console. There may be several entries for Software for instance, all with a slight variation of the work ‘software’. To remove Metadata corruption, run DBREPAIR.EXE from LANDesk Software Inc. to remove unmodeled/Unwanted metadata. See this document for more information: How to download the Database Repair Utility (DBRepair.exe)
Check 6 - ErrorScan Folder
This folder is unlikely to be empty. Scan files that are rejected due to inconsistency or because they are duplicate devices (see later) will be moved to this folder. Examine the contents of this folder to determine how many new scans a day are being moved here. If this is more than 5% of the total number of managed devices, then there is potentially a problem with system. If the customer is currently in the process of redeploying the LDMS agent, or is currently reimaging or migrating a large number of devices, then it may be normal to see a larger number of scan files in this folder.
One thing to check is the Event Viewer on the core. There are usually 4100, or 4110 errors related to this. Usually DBrepair,exe or Updating datamart.xml and running coredbutil.exe or manually making the SQL char value bigger for specific tables will fix these errors. See the following documents.
Error in Application Event Log: Item cannot be found in the collection corresponding to the requested name or ordinal - Event ID 4100
Database Exception "The size of Table.Field is too small. Increase its size by at least xx." Event ID 4110
|Verify the Configuration of the Inventory Service|
Log into the LANDesk Console on the LANDesk Core Server itself, with administrator rights. Go to "Configure | Services" and select the Inventory tab. You will see the configuration options for the Inventory Service on the core server.
Tip! The services can ONLY be configured from the core.
Check 7 - "Days to keep Inventory Scans" Option
This will be set to zero by default, which equals infinite. Scans won't ever get erased. Once an inventory scan is received and processed, that device will remain in inventory. It will also count against the total number of licenses in use. The problem is, what should happen if that devices is reimaged (and potentially acquires a different unique ID) or if the device is disposed of, lost or stolen?
We potentially have devices inventory that no longer exist, or which are duplicated. By setting the "Days to keep inventory scans" to a value other than zero we purge devices which have not recently sent an updated inventory scan: the assumption is that the device no longer exists, or has acquired a new unique ID. Discuss this with the customer and consider setting the value to something conservative like 90 or 180 days. This will have the added benefit for the customer of reclaiming LANDesk licenses that are not being utilised. Changes will take effect when the server next runs its maintenance task (configured from the above dialogue box).
Tip! You can cause the scheduled maintenance cycle to run immediately by setting the "Perform Maintenance at" time to the current hour and restarting the inventory service. The minutes are ignored in this setting! Look in the Application Event Log to confirm that Maintenance has completed successfully. It should run within 5 minutes of the inventory service starting.
|Dealing with Duplicate Devices|
Devices get reimaged, and hard disks get replaced. Sometimes a customer will create a "Gold" image and deploy this image to multiple devices, and they may forget to remove the Unique ID setting from the registry prior to creating the image. These situations can result in duplicate devices in inventory. There are settings that will help prevent this, and settings that will clean up duplicates.
Check 8 - "Devices" Settings
*-Note - This setting is for inventory that has already been processed and resides in the database. This is not realtime. It runs on a schedule daily. The time for this schedule can be changed under Configure-> Services -> Inventory -> Perform maintenance at. If you are looking for the settings for what happens when the inventory is processing new inventory scans, please see Check 9.
From the Inventory Services settings dialogue box shown above, click on the "Devices" button. You will see the following:
*This shows the recommended settings. If during the routine scheduled maintenance operation the service finds two or more devices where both the MAC address and Device name are the same, the older inventory items will be automatically deleted. Verify that the above settings are configured, or that the LDMS administrator has a good reason for selecting and alternative configuration. Note that this option does not prevent the problem from occurring, it simply cleans up afterwards.
Check 9 - "Device IDs" Settings
*-Note - This is the settings for what happens when the inventory processes new inventory scans, and what to do with similar items.
From the same "Configure | Services | Inventory" dialog box it is possible to access the Device IDs settings. They look like this:
These settings actually help prevent the problem of duplicate devices occurring. The above settings are the recommended settings for most customer environments. When an inventory scan arrives and is being processed by the inventory service the data is compared to existing inventory. If an inventory scan is received where the Unique ID is already in the inventory database, but the device name and MAC address do not match, the scan is rejected and moved to the ErrorScan folder mentioned earlier. In addition, the Unique Device ID itself is marked as being "Bad" and any future inventory scans using this Unique ID will automatically be rejected. Any device attempting to submit an inventory scan using a "Bad" Unique ID is told to generate a new Unique ID. This is the purpose of the "Reject Duplicate Identities" option - which is checked in the above screen shot.
Customers may have added additional attributes to the list of "Identity Attributes". It should not necessary to do so. If additional attributes have been added, it is important that they are genuinely attributes that help to uniquely identify a device, such as an asset tag or manufacturers serial number. It is possible then trigger the rejection of scans based on, for example, two out of three attributes being different. That is the function of the "Identity Attributes Change" option. The default configuration shown above is the best configuration in the large majority of cases.
Correctly configuring this option will deal with the situation where the customer is using a "Gold" build image which already contains the agent configuration, or more specifically the Unique ID in the registry. Depending on how often the agent is sending an inventory scan, it can take several days to clean up after an image has been deployed. The first scan is rejected, and only when the second scan is about to be performed will the agent generate a new Unique ID.
See this document for more of an in depth explanation regarding the Devices and Device IDs settings.
Check 10 - Column Sets
Some customers change the default columns for the network view. One issue that comes up is if you choose a column with multiple entries such as Computer-Memory-Slots-Memory Slot-Installed Size, then the view will list the machine multiple times, 1 for each entry. See photo below.
The way to fix this is to identify the column that has the multiple entries, and remove the column.
To Create a Column Set
1. Click Tools | Administration | Column Set Configuration
2. Right click My Column Set and click New Column Set...
3. In the Column Configuration dialog, enter a name for the new column set
4. Select inventory attributes from the list and add them to the Columns list by clicking Add to columns. Remember to select attributes that will help you identify the devices in the device list or returned by the query
5. (Optional) You can customize how and where the columns appear in the network view by directly editing a component's heading, alias, and sort order fields; or by removing or moving the selected component up or down in the list with the available buttons
6. (Optional) You can specify more precise qualifying data for software components. Select the software component, click the Qualify button, and then select a primary key value from the list of available values
7. Click OK to save the column set
To Apply a Column Set
1. Click and drag the column set into the network view on the right or drag over the device group on the left
Landesk Management Suite 9.5
Landesk Management Suite 9.5 Sp1
Landesk Management Suite 9.5 Sp2