Software inventory with Win32_Product in Windows

manage the software inventory in Windows It's one of those tasks that almost nobody wants to do, but that sooner or later you have to face, especially when you manage several teams or have to leave some portable “Clean” for production. In this context, the WMI class Win32_Product It usually appears as the quick and direct option to check installed applications, automate uninstallations, and validate MSI-based installations.

However, relying on Win32_Product Without a full understanding of what it does behind the scenes, it can lead to unpleasant surprises: from significant script delays to silent repairs of MSI packages. Furthermore, not all software is installed via Windows Installer, which complicates inventory management and automated uninstallation. In the following sections, we'll take a detailed look at how to use Win32_Product, what alternatives exist in PowerShell and the registry, how to obtain product GUIDs, and how to run scripts safely and efficiently in modern Windows environments.

What is Win32_Product and what software information does it provide?

The WMI class Win32_Product It is part of the namespace root\cimv2 from WMI and is designed to represent installed products using Microsoft Windows Installer (MSI)When queried, it allows you to obtain key data about the MSI packages present in the system, such as the name, version, vendor, or product identifier (GUID), among other attributes relevant to administration.

Among the most useful properties of Win32_Product These include the product name (Name), version number (Version), vendor (Vendor), product identifier (IdentifyingNumber), and local package location (LocalPackage). These properties are especially valuable when you need inventory MSI software, check which version of a critical application is installed or uniquely identify a product to uninstall it using commands automated.

It is important to be clear that Win32_Product only returns software installed with Windows InstallerAny programs installed using custom installers, EXE installers, other packaged applications, or software from the Microsoft Store will not appear in these types of queries. Therefore, while this is a powerful tool, it does not cover the entire application inventory of a computer on its own.

Microsoft's technical documentation refers to resources such as TechNet ScriptCenter For additional examples of scripts that use this and many other WMI classes, see the resources below. These resources demonstrate practical use cases for enumerating, filtering, uninstalling, and auditing software installed via MSI, both on local and remote machines, using various scripting languages.

Run WMI scripts for software inventory

Although nowadays most administrators are inclined to PowerShellThere are still many environments where Microsoft examples and classic documentation rely on VBScript and WMISoftware inventory scripts are usually run against the local machine, but with minor modifications they can target remote machines if adequate permissions and connectivity are available.

The typical Microsoft guide explains a simple procedure for Run scripts with the .vbs extensionThe general flow consists of writing the code for the scriptsave it with the correct extension and run it from the command line using cscriptso that the output remains in the console and the Windows Script Host graphical interface is not opened.

The basic process for launching one of these scripts involves copying the example code and saving it to a file like name.vbs (making sure the editor doesn't add ".txt" to the end), open a window of symbol of the system, change to the directory where the script was saved and run a command of the type cscript name.vbsThis approach is valid both for scripts that only read information and for those that perform actions such as uninstallations.

It is important to take into account the permissions required to access certain resourcesIf the script queries sensitive information, such as some protected event logs or system areas subject to User Account Control (UAC), it may be essential to open the console with elevated privileges (Run as administrator) for it to function correctly.

Although many examples focus on the local computer, Microsoft documents in detail how Connecting to WMI on remote computersUsing connection strings that include the computer name and credentials with appropriate permissions, it is possible to scan multiple machines and collect software information centrally, which is very useful in audits or mass deployments.

Uninstall MSI software using Win32_Product

One of the most striking capabilities of the class Win32_Product It not only allows you to list installed MSI applications, but also uninstall them using the Uninstall methodThis opens the door to automating the removal of unwanted software from dozens of computers without having to manually navigate through the Control Panel.

In VBScript, the typical approach is to connect to the desired machine's WMI service, run a query on the Win32_Product class filtering by product name, and then iterate through the resulting collection by invoking the method Uninstall() on each instance. This way, a specific application that was installed using Windows Installer can be silently removed.

A script in classic Visual Basic usually follows a pattern similar to the following: the target computer is defined (usually “.” to indicate the local machine), a WMI object is created pointing to root\cimv2 With the appropriate level of impersonation, a query “Select * from Win32_Product Where Name = 'Product Name'” is executed, and for each returned object, the following is called: objSoftware.Uninstall()The result is that the specified application is uninstalled without any manual interaction.

En PowerShellThe logic is very similar but with cleaner syntax. It is used Get-WmiObject -Class Win32_Product To retrieve all MSI products, filter with Where-Object by the desired name and, in a loop foreachThe method is called Uninstall() of each matching object. This approach is perfect, for example, for bulk deleting a corporate package that is no longer desired to be kept in the equipment fleet.

However, it is important to remember that Win32_Product may have side effectsWhen products with this class are listed, Windows Installer may trigger health checks and repairs of corrupted packages. In large production environments, this behavior can generate significant traffic, CPU usage, and delays, so many administrators prefer other methods for inventorying software and reserve Win32_Product only for very specific cases of controlled uninstallation.

Using PowerShell to list installed software

When it comes to obtaining a list of installed programs, PowerShell offers several alternativesSome are based on WMI, while others rely directly on the Windows Registry. There isn't a single command that works perfectly for all scenarios, so it's often helpful to combine several techniques depending on the type of software you want to detect.

The most direct command, although not always the most advisable, is Get-WmiObject Win32_Product (or its alias “gwmi Win32_Product”). This command uses WMI to list all MSI products installed on the system. It is very convenient because it returns property-rich objects, but it has the drawback of potentially causing repairs and of excluding any non-MSI programs.

To cover more software, many administrators turn to the registry. inventory programsThe keys to HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall and its counterpart HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall They store information about installed 64-bit and 32-bit programs, respectively. With PowerShell, you can execute a command like Get-ItemProperty on these routes to retrieve values ​​such as DisplayName, DisplayVersion, Publisher or InstallDate.

A classic approach involves using gp (alias of Get-ItemProperty) on both paths and filter for items whose DisplayName is not empty. Then, select only the DisplayName property to obtain a quick list of applications visible in "Programs and Features". This avoids relying on WMI and captures many more installers, including those not based on MSI.

If more complete information is needed, somewhat more elaborate commands are usually constructed that call on Get-ItemProperty and then they use Select-Object to display various properties, such as the display name, version, manufacturer, and installation date. Finally, it is applied Format-Table -AutoSize so that the output is readable on the console. This can be done with either the standard 64-bit branch or the Wow6432Node branch to cover 32-bit software.

Another available tool is WMIC (Windows Management Instrumentation Command-line), which, although deprecated in the most recent versions of Windows, is still seen on many servers and workstations. A command like wmic product get name,version It lists the names and versions of MSI products, proving useful when you need a quick result without entering complex scripts.

DisplayName, UninstallString, and registry keys for uninstalling

Beyond WMI, a very important part of Software inventory in Windows is based on the registryEach installed application usually has a key within the Uninstall paths we mentioned earlier, and within that key are located values ​​that are fundamental both to display the application in the Control Panel and to automate its removal.

Two of the most interesting values ​​that are usually found in each entry are display name y UninstallStringThe first one corresponds to the name seen in "Uninstall or change a program" within "Programs and Features" in the Control Panel. That is, the text the user recognizes as the application's name as seen in the graphical interface.

The value UninstallString It's even more valuable for administrators because it contains the command that Windows executes when the uninstall button is clicked in the Control Panel. Often, it's a call to... msiexec with a GUID and several parameters, or a proprietary executable from the manufacturer with specific options. Knowing this string allows you to launch the uninstallation remotely or automatically from PowerShell scripts, VBScript, or other management tools.

If these keys are examined using PowerShell Get-ItemPropertyValues ​​such as DisplayName, DisplayVersion, Publisher, and UninstallString can be combined to build comprehensive application listings with all the information needed for inventory, auditing, and uninstallation. This approach is very flexible, as it is independent of the installer type (MSI, EXE, etc.) and does not trigger repairs associated with Win32_Product.

Visually, all of this is reflected in the window of “Uninstall or change a program” which we find in Programs and Features. Each line in that list typically corresponds to a registry entry in the paths mentioned, with a DisplayName and usually an associated UninstallString. Understanding this relationship helps diagnose why an application sometimes doesn't appear in the Control Panel, or why a manual uninstallation doesn't work as expected.

Obtain GUID and detect software without MSI

In real-world practice, one of the recurring challenges is locate the GUID of an installed product to be able to uninstall it using msiexec or deployment tools. When dealing with MSI packages, Win32_Product makes the job much easier, since the IdentifyingNumber property returns precisely that GUID in standard format.

For example, if you use a command like Get-WmiObject Win32_Product | Format-Table IdentifyingNumber, Name, LocalPackage -AutoSizeThis output produces a table with the product name, its GUID, and the location of the MSI file in the Windows installation cache. This type of output is very useful for verifying that a corporate agent (such as fraud detection solutions or security tools) is correctly installed and can be managed via MSI.

The problem arises when a program does not appear as classic MSI productIn some cases, tools distributed as EXEs or using different providers may have a different ProviderName, for example, "Programs" instead of "msi". In these situations, trying to obtain the GUID using only Win32_Product will not work, because there simply isn't an MSI identifier that can be passed to msiexec.

A typical scenario in corporate environments is that of a technician who receives several laptops (for example, a batch of HP ProBooks) pre-installed with software from the manufacturer. Part of their job involves remove all bloatwareFor many pre-installed programs, simply checking Win32_Product or the Uninstall keys will provide the GUID or uninstallation string. However, there are always a couple of applications that don't follow the standard pattern.

When the ProviderName is “Programs” or another value not associated with MSI, it is usually necessary search for the uninstallation string directly in the registryThere, in UninstallString, you can find the command the system uses to remove the application, even without a typical Windows Installer GUID. From that string, you can create scripts that call that executable with the appropriate parameters to uninstall it silently.

In more complex cases, if the vendor doesn't provide a clear MSI or a standard UninstallString, you may need to use additional tools or consult the vendor's specific documentation. However, in many environments, most of these scenarios are resolved without installing extra software, relying solely on PowerShell, WMI, and the system registry.

Verification of specific agents and tools with Win32_Product

In addition to general inventory use, there are specific scenarios where organizations need to validate at a low level that a a specific software agent is present and properly installed. A typical example is the agents responsible for monitoring, security, or fraud analysis, which must be deployed uniformly across the entire fleet of equipment.

In these cases, a command like get-wmiobject Win32_Product | Format-Table IdentifyingNumber, Name, LocalPackage -AutoSize This is very practical. The output provides the product name, product ID (GUID), and the location of the MSI file stored in the Windows installation cache. With this information, you can verify that the correct package is installed and that its MSI is available for possible repairs or controlled uninstallations.

Certain commercial solutions, such as advanced fraud detection platforms, explicitly document the use of Win32_Product as a supported method for verifying your agent. These manuals emphasize that the Returned information is confidential and is intended exclusively for authorized clients, prohibiting its publication in open or publicly accessible sources, which underlines the sensitivity of some corporate environments.

Another common use of Win32_Product is quickly identify the version of an office suite , the Microsoft OfficeInstalled via traditional MSI. Simply filter by product name and check the Version property to see which specific release is on a machine, which is very useful when managing migrations or mass updates and needing to know the starting point of each machine.

These types of checks combine very well with centralized inventory systems y remote management toolsAlthough Win32_Product isn't ideal for a massive scan on hundreds of computers at once, it is very convenient as spot check or as part of post-deployment validation scripts.

Master the different sources of information about software installed on Windows (WMI, registry, Control Panel and command lines) allows you to tackle tasks such as inventory, bulk uninstallation, agent verification and version control with much more ease and less improvisation, which ends up saving time and headaches in the day-to-day administration of systems.