Every now and then someone will question the support terms of one of my open source projects, such as ldms_client. (To refresh those terms, they are: email me and I'll see if there's something I can do when I've got time to work on it.) Users who are unhappy with such terms will occasionally then go to the trouble of implementing their own custom solution to their inventory extension problem.
Chances are good that such a solution will not be supported either. Bearing in mind that I don't work in LANDesk support and am only guessing at what a given engineer will do on the day you call for help, my opinion is that LANDesk's support will center around successfully running the command and transferring the data.
ldms_client uses supported methods to do that, and so do the vast majority of the homegrown scripts that I've seen. But if either your script or ldms_client quit working properly, LANDesk support is within their rights to quit troubleshooting when they determine that LDMS can still execute programs and upload custom data. If the framework is working but your AV client is blocking your VBscript from copying a value out of HKCU into HKLM so that LDAPPL3.INI can pick it up, that's not really LANDesk's problem.
ldms_client exists because someday you'll come across another need for some goofy inventory extension, and someday they'll quit asking for this one... When you start trying to turn extensions on and off without its framework, you'll probably wish you had it.
While we're on the subject of "custom work" - another grey area is modelled Custom Data. This does have a public support document linked to it, which can be found here:
http://community.landesk.com/support/docs/DOC-2538
I cannot stress the importance enough of "getting this sort of thing RIGHT on a test system first". The process of trying to model your own data is going to involve repeated attempts at "getting it right" for the first few times at least.
Since "getting it wrong" should require a DB-rebuild from scratch (best - snapshot of a VM before you add the custom tables, so you can modify your custom table XML easily), this is very obviously you DO NOT want to do on a live, production database.
DB modelling will only be helped in part by support - the white paper exists, so the "basic instructions" are there, and more would have to be called on a case by case basis (as the line between consulting work and support work gets very blurred and decisions are based on a case-by-case basis).
Hope this sets expectations somewhat correctly.
Paul Hoffmann
LANDesk EMEA Technical Lead