Now you’re opening a can of worms. Basically, many recommend not using it because it’s not really software inventory, it’s file inventory. File and software are kind of sort of synonymous depending upon context, but not really. Thus, simply because an exe or dll exists on a system, does not mean that software actually exists. Is a good indicator? Yes, but “good” is very subjective here.
So why not use it? Because add remove programs is a better source of what software is actually installed for *most* purposes. This is collected by hw inventory and not software inv (because as mentioned, sw inv collects files). Another reason not to use it is because unless you carefully target your collection rules, you can impact performance of the client systems. This is because as a file inventory mechanism, it literally must scan every file on the system. That’s hundreds of thousands of files (if not more) and scanning those files can in turn be impacted by many things like [over-zealous] AV, disk fragmentation, other things accessing the disk, etc. On new, desktop systems, it’s hard to contemplate it actually being noticeable by users, but it is possible. Now think about laptops/tablets with slower 5400 RPM driver though and ATOM processors or VDI or those of you doomed to run CrapAfee. There also is a four-hour timeout so if any (or all) of the reason above (or others) cause the scan to take more than four hours, it simply quits. Finally, do you really want to bloat your DB with info about every DLL and EXE on your managed systems? That depends upon if you actually are going to use that info which some folks and products do – like Secunia and Snow. Note that by default SW Inv is enabled in 2012 but not configured to collect anything. An additional factor crops up in 2012: They added throttling so that sw inv can take days to finish on a single system and won’t even start until hours after the scheduled time. Sherry has a great post on this. So, it all comes down to this: - Know that Software Inventory is *not* “software” inventory, it is a file inventory; i.e., use the right tool for the job at hand and to answer the questions you need to answer. - Target and limit your SW Inv collection rules so you aren’t scanning the whole disk (if possible) and only if you truly need and will make use of the file info collected. - Only collect the data when you need it; i.e., turn off the rule if you aren’t actively using the data anymore. - Be aware that you *may* (or probably will) be impacting users. - Don’t expect results quickly (particularly in 2012). - Use Compliance Settings to look for specific info; e.g., if you want to know if a specific exe or dll exists. Compliance Settings is far more efficient and flexible and can provide results quicker without bloating your DB or bogging down the network. Garth has some strong feeling on this as well so read his reply and the post he linked to – he basically says don’t do it … ever. I obviously don’t go that far, but his points are valid and so you need to consider them also. J From: [email protected] [mailto:[email protected]] On Behalf Of Burke, John Sent: Thursday, October 29, 2015 9:13 AM To: [email protected] Subject: [mssms] SCCM 2007 R2 - Software Inventory is Incredibly slow Hi folks, We haven’t gotten the chance to upgrade to 2012 yet so I’m stuck with 2007. We are noticing a fair number of clients that are semi healthy with the exception of software inventory. I’ve seen some posts that simply say don’t bother using Software inventory because it’s too slow. That seems a bit silly. Why have the feature at all if it’s going to be useless. In our environment we often create collections based on exe versions or dll versions for upgrade purposes. Internet Explorer for example – seems to be something that you need software inventory to deal with. So – I’m wondering what you folks do with Sofwtare Inventory. Do you bother using it? Did you tweak it somehow to make them faster so they it doesn’t take hours?
