What you see in your control panel is a filtered assembly from several different sources. An easy way to come close to a similar list is by using WMI / CIM:
Just an FYI, Win32_Product has itâs drawbacks, the worst of them being that on Windows 10, it triggers a ârepairâ on every product which takes forever. Just google âwin32_product bad ideaâ for more details.
I wound up writing a function that enumerates both the 64bit and 32bit registry entries, removes duplicates, then pipes that through âConvert-ToHTMLâ. I could not afford to wait the time Win32_Product takes to enumerate when there might be 100âs of products installed.
I never needed to create a software inventory like this with PowerShell but when I tried to use Win32_Product Iâve never experienced any problems besides the lack of speed generating the list.
Anyway, I think there are a ton of examples for tasks like this out there and I suspect @Rahul20 just picked the worst one of them. Depending on the purpose of the task there are probably better options than that. To be more helpful we should have more information about the âend goalâ.
Makes sense Olaf. I tried to use it, but the systems I was auditing had over 300 (many over 400) products installed and just this one section of my audit was taking 20+ minutes per system. When I went to the registry approach, it literally went down to a few seconds at best. The original post stated they want the result to look just like Appwiz.CPL ⌠my approach does not do that. I piped the output through Convert-ToHTML. My interest was to sort by date and include the DisplayName, Version, Install Date, Publisher and any comments. I was able to grab all that from the registry.
I tried it on my machine with about 200 products listed and it did not take 30 seconds. Iâd expect most of times it does not matter how long it takes for such a task. In a production environment I wouldnât use this âdirect remoteâ approach as it has other disadvantages. Iâd rather set up a task locally on the remote machines generating the list and deliver it to a central share if there is no other dedicated product in place handling this type of task like SCCM for example.
It looks like you are already using the registry approach which is the same method I used. What is your issue? The only difference between what I did and what you posted is that you are not enumerating both the 32bit and 64bit registry. Just add this to your script for 32bit entries: