Applies to
LDMS 8.7 and 8.8
This document assumes the user has intermediate level SQL Management Studio & LANDesk Management Suite skills.
The corruption referred to in this article is invalid objects and characters which are found in Inventory, the query editor and in dbrepair.exe outside of the Custom Data section.
LANDesk and the article contributes are not responsible for any data lost when running dbrepair.exe. As always backup your database before making any data modifications.
Note: There is a known issue with the LDMS 8.8 SP2 inventory scanner where a carriage return characterset in a registry key will be interpreted by ldiscn32 and it will put a carriage return in the scan file; creating what appears to be corruption. While this isnt overly common, it has been seen in a few environments. Upgrade the Core and the agents to 8.8 SP3, or contact support for hotfix INV-2415688.2-2 (8.8 post SP2 patch). This patch must also be applied to agents, or the agent must be redeployed as the fix is within the Inventory Scanner.
Overview
Corruption has two primary sources: Client and Core.
Client side corruption can take place when there is corruption during the inventory scan process and some invalid characters are sent up to the core. Because clients send delta's and also sync their records, then the unmodeled records will often be removed on the next scan. However the attributes are left in the meta tables (the core considers this data unmodeled or custom data and not corruption).
Core side corruption can occur when queries are run or evaluated that contain invalid or corrupt attributes. If a query contains corrupt attributes, then the corruption will be re-added every time this query is run, or evaluated.
It can be difficult to tell which of the two sources the corruption is coming from without some investigation. However a good starting point is if the exact same corruption is occurring regularly, but querying for computers with these attributes returns no computers then it is more likely Core side. (LDMS Query: "computer.corruption - exists")
Client Troubleshooting
If there are suspect characters showing up in the inventory tree after processing inventory scans, it is more effective to troubleshoot the problem at the source (computer) than running dbrepair constantly. In some cases computers will send the same values again repopulating the unmodeled data and or meta tables with bad data.
Example:
![bill.JPG]()
From the query editor expand the corrupt tree, select an attribute and choose exists, Insert and save the query. Normally this will give the results needed however sometimes a precise database query is needed.
Here is a query that will find out the computer_idn(s) for the offending machines. This query assumes that a record has been entered into unmodeled data. There are two configurable options in the query. Oracle users: see attachment oraquery.txt, remember to replace the value in the last line 'Profile Size' with the suspect object found in the query window.
select distinct a.computer_idn
from computer as a
Inner Join unmodeleddata as b
on a.computer_idn=b.computer_idn
Inner Join metaobjattrrelations as c
on b.metaobjattrrelations_idn=c.metaobjattrrelations_idn
Inner Join metaobjrelations as d
on c.metaobjrelations_idn=d.metaobjrelations_idn
Inner Join metaobjects as e
on d.metaobjects_idn=e.metaobjects_idn
where e.ENU = ')Bill'
1) There are different options available where ENU is used. "OBJECTNAME"," DEF", or the appropriate language such as "ENU"
The above query uses the language column because that contains the value which will appear in the console. If the query isn't returning expected results then try OBJECTNAME or DEF. This is an unlikely scenario as generally the value will be the same for all three columns.
2) Replace )Bill with the corruption found in the query window.
The query will return the computer_idn(s) from unmodeled data that have a relationship to the object in question. If no rows are returned from a properly formatted query then it means there is no entry made in the unmodeled data table for the computer and the metaobject(object that appears in the query window). If this happens then troubleshooting by client is less feasible. Either the corruption is from the core, or the client has since sent a delta deleting the corruption.
Once computer IDN's are returned a user can run the following SQL query to get more info about the machine. Replace 1 with the idn(s) returned in the query.
select * from computer where computer_idn = 1
The computer_idn is also an inventory item and can be queried off of in LDMS.
![computerid.JPG]()
Once a list of computers is compiled then there are a few main causes to corruption.
- Old Inventory scanner - Schedule an agent deployment to the client.
- Bad WMI or information returned by WMI - attempt a repair of the WMI.
- Machine software or driver returning the corruption is out of date - try the same software/driver on a different machine or even a reinstall.
- Incorrectly formatted registry key - reinstall the application/driver in question.
- A carriage return in the registry as described at the beginning of this article - upgrade to 8.8 SP3.
In some cases an update is needed to the inventory scanner from LANDesk so it can scan certain values. This is generally only the case when the scanner always returns incorrect data on a certain field across multiple machines.
Core Troubleshooting
Troubleshooting on the core is recommended to be done during a maintenance window or low usage time where only one console(Win or Web consoles) is being used. This is because dbrepair.exe (attached) will be used repeatedly to clean data and many queries will be run in an attempt to reveal the source of corruption. If others are using consoles or running queries, the tests will not be accurate.
1) Close all consoles and Create a backup of the database.
2) Open dbrepair.exe -attached (from the ManagementSuite folder on the core).
3) Click on and clean the child folders of computer except custom data. Also, do not click on computer and clean, this will remove all custom data.
Once done the window should look like so:
![CleanedMeta1.JPG]()
4) Next open the console and begin running queries. In order to run all of the queries, log in as a LANDesk administrator and run through the user queries.
5) Periodically open dbrepair.exe to determine if the corruption has returned.
6) Run through every (user) and (public) query in the console, also restart the scheduler service (causes target evaluation) and finally run all of the queries under the Users tool for scopes.
7) If any of those queries had corrupt attributes then the corruption will return in dbrepair like so:
![NewCorruption.JPG]()
8) Now it is just a matter of finding the query(s) responsible by opeing them and viewing them or process of elimination.
9) Remove and rebuild any queries causing corruption including Scope queries.
Additional notes
If it is still unknown where the source of corruption is but it still keeps coming back then do the following.
1) Back up the database or create a copy.
2) Restore it for lab use. Use dbrepair.exe and clean out everything except custom data.
3) Connect a lab core server to the database copy/backup. This lab core should not receive any client traffic.
4) Do not import any scans or send any new traffic to this core. Simply attach it to the database leave it in a running state, and only do console actions which do not request any type of scans from clients.
5) If the corruption is client side, then it will not appear in this lab instance. If it is core side, then most likely it will as long as the function that creates it has been run. There are other Core functions that may generate metadata outside of the inventory process which have not been included in the scope of this document.
