Home > Database, Deep Dives > External Unmodeled Data

External Unmodeled Data

September 14th, 2010 Leave a comment Go to comments

The LDMS database is a very useful gathering of near real time inventory data. However, there are times when you’ll want to extend that data source with other information. You might want to start by reading this excellent document on the data model.  Here are the currently available options:

  1. Put the data on the endpoints and gather it from there.
    • This is the easiest concept to follow and implement, requiring very little advanced work outside of LANDesk native tools. Simply put, you take the bits of data you want and put them on the machines they affect in the form of registry keys, then gather that data with an Inventory Extension or Custom Vulnerability. There’s many very useful examples of this technique on droppedpackets and at the community, but one of the bigger bang-for-buck ones to try out is the ExtendInv tool, which resolves AD users and groups in your local groups. If you’re interested in generally popular inventory extensions, a lot of them are rolled up into the ldms_client tool.
    • However, this model has multiple problems, as well… for instance, imagine the security, performance, and logistics implications of hundreds of machines logging directly into SAP to pull their data into the registry, or restoring the proper data after an OS Deployment job. If your data is truly local, as in ExtendInv’s case, then this is the right solution. Otherwise, you’ll need to consider security first, performance second. Performance is generally not as important if you architect your solution properly, because the downloads should only happen when necessary; however, depending on the data source, read access might be tightly controlled.
    • The biggest advantage to this method is that the data stays “alive” and valid; as long as the machine still has the registry key, for instance, the content of that key will be part of the machine’s inventory, without a lot of fuss.
  2. Copy the data into LDMS on a regular basis.
    • This is a lot harder, and potentially fraught with danger. You’ll want the help of a DBA, if you aren’t one yourself. The first thing you’ll need to do is decide whether you want to use unmodeled data or a schema extension. The answer to that question is that you probably don’t want to do a schema extension… a single typo will mess up your life, and upgrades get a lot more complex.
    • First: Get the data from the other source: CSV output, database triggers/stored procedures, SOAP request using the SDK, what works in your environment? TODO: examples.
    • Second: Insert the data into LANDesk: TODO: describe unmodeleddata tables.
    • Third: Maintain the data: script this to keep it happening. Unmodeled or not, data in the inventory database is based on the PC scans. Incoming scans from PCs which do not contain your contract info will overwrite what you’ve imported with nothingness, so you’ll need to come up with a way to correct for that.
  3. Use a third tool as your interface which can read multiple sources to view the data (e.g. LANDesk Service Desk). This way relatively real time data and relatively static data live in their own homes and maintain their own supportability, while your external display tool reads from them both and maps them together.
    • Text. TODO: Examples.
Categories: Database, Deep Dives Tags:
  1. No comments yet.
  1. No trackbacks yet.
You must be logged in to post a comment.