I - Introduction

PLEASE NOTE:

This is very much an advanced user article. Whilst most of the steps here "merely" make use of select-statements and are thus non-destructive, it should be noted that any direct access to the database should be handled with careful consideration & respect.

This article is applicable for the following versions of LANDesk Management Suite:

- LANDesk Management Suite 8.x (all of them)

- LANDesk Management Suite 9.x (all of them)

Until the software goes through a considerable to complete re-architecture of the entire database back-end, there's no reason why anything here should change and/or become invalid.

II - Preparation and general recommendations

II.A - First Steps

I would strongly advise going through this first of all on a test core (with a small database).

It is considerably easier to understand the relationships between everything for yourself in a small scale first, and then to move up to a full production DB once you're comfortable with what you're doing.

This is *not* SQL training. It is expected that persons making use of this will have at least rudimentary skills in working with databases and using SQL. I endeavour to explain as well as I can, but if you do not know what databases or SQL statements are, and you're being asked to this kind of work, you will need to learn those concepts first.

II.B - What is Metadata?

Meta data is - simply put - "data on data".

For instance, if we were to describe various lawns, they'd have categories such as "Colour is very green" or "Colour is rather brown", "Cleanliness is clean" and "Cleanliness is messy" and so on.

Meta-data is information ON this - so it would for instance say "A Lawn has two attributes – one is ‘Colour’, and the other is ‘Cleanliness’.”

So – while this is not “real data” in regards to “is this a dirty lawn?” or “is this a green lawn?”, it is very much necessary information in order to quantify what attributes a lawn can have, and as such necessary in order to define a thing (be it a piece of data or a lawn).

III - Understanding the relationships between tables.

The following graph serves as a basic guideline of how default "custom data" is linked together through the relevant DB-tables.

III.A - The UNMODELEDDATA table

This table holds all custom data (as well as other forms of "non standard" data).

The data is linked to each individual device via the COMPUTER_IDN (the primary identifier for all devices in the DB).

Equally, the actual "attribute instance" is linked to via the METAOBJATTRRELATIONS_IDN (explained below).

Ultimately, our aim is to collect the DATASTRING values for our targeted COMPUTER_IDN's and/or just the METAOBJATTRRELATIONS_IDN's (and all devices) that we intend to target.

In essence, the question to be answered is either of the following:

- Do I care about a particular subset of custom data for ALL my devices?

or:

- Do I care about a particular subset of custom data for SOME of my devices?

III.B - The METAOBJATTRRELATIONS table

This table is the "go-between" - it links actual data attributes (things such as "Computer Name" or "Location")

What's the difference between an object and an attribute?

An 'attribute' is a "final" data object. So for instance, "4096 MB" would be the data-value for the attribute "System Memory available".

 

The "object" would be the 'data path' leading down to the "System Memory Available" attribute. So for instance the "Hardware" folder in inventory, is an Object.

 

A simple way to remember is as follows:

"Everything that looks like a folder in inventory is an object".

"Everything that holds an actual data value is an attribute"

The important part here is that this is only a linking table for our data.

III.C - the METAATTRIBUTES table

This table is the table storing all attributes's definitions. An attribute is something like "VendorID" or "LastVirusScanDate" - any kind of actual data field is an attribute.

This does not hold the actual data VALUES for these fields, it holds the data of the data field itself (i.e. - the answer to the question "where can I find this in the database").

IV - A real-world example via walk-through

In the following, I’m going to include various screenshots, to show how we’re going to find a specific set of values through SQL that we’re looking for.

IV.A - Finding what we look for

First of all – let’s take a look at the METAATTRIBUTES table as is:

SQL used:

-- Show me everything in the METAATTRIBUTES table
Select * from METAATTRIBUTES

Notice that I’ve highlighted two types of data in the ATTRNAME column:

• The “StartMenuFolder” – which is normal LANDesk data (check the ATTRNAME column).
• The DATASTRING-s – this is custom data

NOTE:

LANDesk Custom Data will ALWAYS have an ATTRNAME of “DATASTRING” by default. The exception to this rule is only if you've written custom tables to hold your custom data, but this would be a separate action all together.

So – let’s refine the query a little, to have the whole thing more manageable and see what custom data we actually have available in the database.

SQL Used:

-- Show me just Custom Data
select * from METAATTRIBUTES where ATTRNAME='DATASTRING'

IV.B - Choosing Data

As an example in this case, we want to find “Pending File Rename”, which has a METAATTRIBUTES_IDN of “1552” – this is the important value to note down, as this gives us the link to this attribute in other tables.

You *CAN* use multiple METAATTRIBUTE_IDN’s – as normal in SQL, but in order to keep things clean and simple, sticking to a single attribute at a time, will be easier.

IV.C - Bringing it all together

If you look back to section III above, at the graph showing the relationship between the tables, you’ll be able to write SQL such as the below, since you now know what to filter by.

SQL Used

-- Show me all information from UNMODELEDDATA for the "Pending File Rename" custom data
select * from UNMODELEDDATA where METAOBJATTRRELATIONS_IDN IN
(  select METAOBJATTRRELATIONS_IDN from METAOBJATTRRELATIONS where METAATTRIBUTES_IDN=1552
)

Explanation:

We only need to know the METAOBJATTRIBUTES_IDN of the attribute we’re scanning for, as the rest is just “linking information”.

In this case, the nested selects take care of the logic for us. The basic results are perfectly fine and are ready to be refined for better use in reports.

IV.D - Something a little more fancy

As an example, I’ve create a slighty more modified version of the SQL that I guided to in step # 2.3, this time linking the COMPUTER table into the fray, so as to be able to display device-names, as this is more useful for reports than just a COMPUTER_IDN (which is mostly of use only for queries within the database).

For this undertaking, we need to modify the SQL a little, like so:

SQL USED:

-- Now show me the data with proper device-names
SELECT DISTINCT TABLE_COMP.DISPLAYNAME, TABLE_COMP.COMPUTER_IDN, TABLE_UNMOD.DATASTRING
FROM COMPUTER TABLE_COMP (nolock)
LEFT OUTER JOIN UNMODELEDDATA TABLE_UNMOD (nolock)
ON TABLE_COMP.COMPUTER_IDN=TABLE_UNMOD.COMPUTER_IDN
WHERE TABLE_UNMOD.METAOBJATTRRELATIONS_IDN IN
(  select METAOBJATTRRELATIONS_IDN from METAOBJATTRRELATIONS where METAATTRIBUTES_IDN=1552
)

End Result:

Voila – a nice basis for a report with the data-strings that we were after.

V - In Conclusion

The article should provide you with everything necessary to identify, find and ultimately query through SQL individual CUSTOM DATA value.