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.