Hmm - realistically, I think SLM's / SLM autodiscovery would be better suited here - as this could give you an easier rundown on the numbers too, as well as an interface to deny their usage.
If you're going to be going for the "scripted collection into a specific registry key" the problem you face is still one of identifiers. You COULD of course just have the batch/script do entries like this in the registry:
Software1 == UninstallString_1
Software2 == UninstallString_2
Software3 == UninstallString_3
Software4 == UninstallString_4
... (and so on)
however, the problem arises that in most likely cases, you'll end up having an entry for "Software2" on PC_A be "Bob's application", while on PC_B it could be "MyFavouriteEditor" - or scenarios like this, which will make that sort of data VERY difficult to collect, and collect in such a manner that it's actually useful. On top of that, you cannot just wildcard those values, as currently this simply cannot be read that way - the registry key/values you want to read must be specified top to bottom. And while a simple static list of "Software1" to "Software100" (or however long you want it to be) is easy to do, you end up with the problem that different PC's will mismatch ...
... which is to say nothing of querying this information - that'll be quite a painful thing to query for (and would REQUIRE you to do so through SQL, realistically),
I am assuming from the general tone of your posts, that you DON'T know what the current worst offenders are - which is something that probably will be a lot easier to find out through regular inventory and/or SLM, I would think - once you have the ID's you want to track, things become easier ... biggest for you problem is to identify those GUID's at the moment. And I think that SLM will be the better way to come up with a short(-ish) list of things you actually want to pick up through Inventory (if it's still needed).
Paul Hoffmann
LANDesk EMEA Technical Lead.