It's no secret that I'm not a fan of using Software Inventory (SWINV). So when I recently got a request to report on whether certain files existed on machines I decided to do something a little different.
I was asked to find out if a list of 9 dlls existed within a specific folder on machines. Normally you'd create a rule for each of these (or one generic rule) in SWINV, wait for machines to get the new policy and run SWINV and send the information back to the site. Instead, I chose to write a PowerShell script that would return the information in one JSON output, and deploy that script as a Configuration Item/Baseline (CI/BL).
This way I could deploy the CI/BL and have the machines return info much faster than waiting for the SWINV cycle. Plus, the CI/BL seems to be more reliable than SWINV.
This may be HUGE for me. I've been looking st the overhead of SINV lately and discovered that it's really not needed for Software Metering as I thought it used to be.
We Meter hundreds of apps so, ad you can imagine, our SINV rules are just stupid at this point.
Your solution looks FAR more efficient and elegant while still retaining all we need, I think.
Question though… if we need to know the meta data of the files (description, oublisher, version, etc), is this also obtained through your method or is it a binary 'this machine has the file(s), this one doesnt'? That's how I read it as I quickly skimmed the code..
Thanks again for this blog (new and old one). It's helped me often!
Thanks GregD! Yes, this specific script is just a "this machine has this file(s)" type of script. However, if you needed additional information from a file you could add that to the script – just store that information in the JSON and it would have what you need. Some of that information could be captured with Get-ItemProperty but you'd have to look into what is there and how to get everything you're needing.