Because that's already part of normal inventory, which you can already run reports on.
Also, bearing the "laws" of SLM (i.e. being file-centric and all that), this would be quite an additional stack of info to cram into databases, which (to my eyes) is unnecessary. The Inventory Scanner already picks up the OS versions - you can report on that.
SLM is for applications.
I suppose we could add this (in which case, you should log an Enhancement Request), but I would primarily see this as a duplication of information that's already being collected so far?
Maybe a bit more explanation could help me understand what you're trying to say?
NOTE - bear in mind that these file-lists would be quite atrociously long, on account of all the different languages out there ...
LANDesk EMEA Technical Lead.
Totally understand your point and am aware of the reports in the OS reports, I just thought it would be convienent to have a 'one stop' shop for all of your compliance with regards to applications and OS's. We are being asked to produce a report on our compliance which involves us gathering lots of information stored on docs and comparing this against the reports produced from LANDesk. What would be great is if we could do something similar to what we do for applications in that we input the licenses information and the LANDesk compliance module computes how compliant we are by comparing the number of installations against the number of licenses against the product (typically XP, Windows 2003 Server, etc). This simple report (although I am not suggesting it would be easy to do) would save me and others gathering this information year on year and would let us clearly show to any prospective auditor in one report our compliance (install count) against the number of licenses (paper/electronic) that we have purchased?
Hope this makes sense and take on all of your points and advice.
Well - at this point, what you're needing/asking for isn't in the product. It won't hurt if you open a support ticket with LANDesk support and get this logged as an enhancement request - the scenario does make some sense after all. But that's a "longer shot".
For the "now", you'll need to work by hand, pretty much - pulling the data out of the database. The information is primarily based in the OPERATING_SYSTEM table - the OSTYPE column specifically. I've traced (on SQL 200x) the SQL that the report is running against the database to give you something to start with:
SELECT DISTINCT A0.DEVICENAME, A1.OSTYPE, A2.CURRENTVERSION, A3.CURRENTVERSION, A4.CURRENTVERSION, A5.CURRENTVERSION, A6.CURRENTVERSION, A7.CURRENTVERSION, A8.CURRENTVERSION, A9.CURRENTVERSION, A10.VERSION, A11.CURRENTVERSION, A2.CURRENTBUILD, A3.CURRENTBUILD, A4.CURRENTBUILD, A3.SERVICEPACK, A4.SERVICEPACK, A2.SERVICEPACK
COMPUTER A0 (nolock) LEFT OUTER JOIN OPERATING_SYSTEM A1 (nolock) ON A0.COMPUTER_IDN = A1.COMPUTER_IDN LEFT OUTER JOIN OSNT A2 (nolock) ON A0.COMPUTER_IDN = A2.COMPUTER_IDN LEFT OUTER JOIN OS95 A3 (nolock) ON A0.COMPUTER_IDN = A3.COMPUTER_IDN LEFT OUTER JOIN OS98 A4 (nolock) ON A0.COMPUTER_IDN = A4.COMPUTER_IDN LEFT OUTER JOIN OSAIX A5 (nolock) ON A0.COMPUTER_IDN = A5.COMPUTER_IDN LEFT OUTER JOIN OSDOS A6 (nolock) ON A0.COMPUTER_IDN = A6.COMPUTER_IDN LEFT OUTER JOIN OSHPUX A7 (nolock) ON A0.COMPUTER_IDN = A7.COMPUTER_IDN LEFT OUTER JOIN OSLINUX A8 (nolock) ON A0.COMPUTER_IDN = A8.COMPUTER_IDN LEFT OUTER JOIN MACINFO A9 (nolock) ON A0.COMPUTER_IDN = A9.COMPUTER_IDN LEFT OUTER JOIN OSNETWARE A10 (nolock) ON A0.COMPUTER_IDN = A10.COMPUTER_IDN LEFT OUTER JOIN OSSOLARIS A11 (nolock) ON A0.COMPUTER_IDN = A11.COMPUTER_IDN WHERE (A0.COMPUTER_IDN NOT IN (SELECT COMPUTER_IDN FROM COMPUTER WHERE COMPUTER_IDN=0) AND A0.DEVICENAME IS NOT NULL) ORDER BY A0.DEVICENAME
If you run Oracle, the YMMV-rule applies and I'd suggest tracing it seperately :).
Hope this helps.
LANDesk EMEA Technical Lead.