Comprehensive Guide to Retrieving Windows Installer Product Codes: From PowerShell to VBScript

Nov 14, 2025 · Programming · 46 views · 7.8

Keywords: Product Code | PowerShell | WMI Query | VBScript | MSI Uninstall | Windows Installer

Abstract: This technical paper provides an in-depth analysis of various methods for retrieving product codes from installed MSI packages in Windows systems. Through detailed examination of PowerShell WMI queries, VBScript COM interface access, registry lookup, and original MSI file parsing, the paper compares the advantages, disadvantages, performance characteristics, and applicable scenarios of each approach. Special emphasis is placed on the self-repair risks associated with WMI queries and alternative solutions. The content also covers extended topics including remote computer queries, product uninstallation operations, and related tool usage, offering complete technical reference for system administrators and software developers.

Introduction and Background

In Windows system management, accurately identifying product codes of installed MSI packages is a critical prerequisite for maintenance operations. As core identifiers within the Windows Installer architecture, product codes play an indispensable role in scenarios such as patch application, software uninstallation, and system auditing. Traditional manual lookup methods are inefficient and error-prone, while systematic retrieval approaches can significantly enhance management efficiency.

PowerShell Retrieval Methods

PowerShell offers convenient access to product information through WMI interfaces. The basic query command is as follows:

get-wmiobject Win32_Product | Sort-Object -Property Name | Format-Table IdentifyingNumber, Name, LocalPackage -AutoSize

It is important to note that within the WMI architecture, product codes are identified as the "IdentifyingNumber" field. This naming difference stems from WMI class design specifications and requires special attention during usage.

Performance Optimization and Risk Mitigation

Standard WMI queries exhibit significant performance bottlenecks and potential risks. Each call to the Win32_Product class triggers comprehensive package integrity validation, a process that is not only time-consuming but may also activate MSI self-repair mechanisms in certain scenarios. Although such repairs can typically be canceled, caution is advised in critical business environments.

COM Interface Alternative

To mitigate the risks associated with WMI queries, direct access to Windows Installer COM interfaces can be employed:

$Installer = New-Object -ComObject WindowsInstaller.Installer
$InstallerProducts = $Installer.ProductsEx("", "", 7)
$InstalledProducts = ForEach($Product in $InstallerProducts){
    [PSCustomObject]@{
        ProductCode = $Product.ProductCode()
        LocalPackage = $Product.InstallProperty("LocalPackage")
        VersionString = $Product.InstallProperty("VersionString")
        ProductPath = $Product.InstallProperty("ProductName")
    }
}
$InstalledProducts

This approach bypasses the WMI layer and interacts directly with the MSI engine, resulting in faster execution speeds and complete avoidance of self-repair triggering risks.

VBScript Implementation

For environments where PowerShell is unavailable, VBScript provides a reliable alternative. The following script demonstrates how to retrieve product information through COM interfaces and export it to CSV format:

Set fso = CreateObject("Scripting.FileSystemObject")
Set output = fso.CreateTextFile("msiinfo.csv", True, True)
Set installer = CreateObject("WindowsInstaller.Installer")

On Error Resume Next

For Each product In installer.ProductsEx("", "", 7)
   productcode = product.ProductCode
   name = product.InstallProperty("ProductName")
   version = product.InstallProperty("VersionString")
   output.writeline (productcode & ", " & name & ", " & version)
Next

output.Close

Registry Query Approach

Although not recommended as the primary method, product code information can still be obtained through registry queries. Relevant registry paths include:

The main limitations of this approach include inability to guarantee data integrity and potential omission of product codes modified through transform applications.

Original MSI File Analysis

If access to the original MSI installation file is available, product codes can be directly obtained by examining the property table. Commonly used tools include Orca, SuperOrca, and other MSI editors. Locating the ProductCode row within the property table provides accurate product identifiers.

Remote Query Implementation

In enterprise environments, retrieving product information from remote computers is frequently required. PowerShell supports remote queries through the -ComputerName parameter:

get-wmiobject Win32_Product -ComputerName RemoteMachine | Format-Table IdentifyingNumber, Name, LocalPackage -AutoSize

Successful execution of remote queries depends on proper network configuration, including firewall rules, DCOM settings, and user permissions.

Product Uninstallation Operations

After obtaining product codes, the most common application scenario involves executing uninstallation operations. The basic uninstall command format is:

msiexec.exe /x {00000000-0000-0000-0000-00000000000C}

For automated scripts, silent mode with detailed logging is recommended:

msiexec.exe /x {00000000-0000-0000-0000-00000000000C} /QN /L*V "C:\My.log" REBOOT=ReallySuppress

Additional Property Retrieval

Beyond product codes, other MSI properties such as upgrade codes hold significant value. These can be obtained by analyzing cached MSI files or using specialized query scripts. Cached MSI files are typically located in the C:\WINDOWS\Installer\ directory with hexadecimal filenames.

Tool Selection Recommendations

Select appropriate tools based on specific requirements:

Conclusion and Best Practices

When selecting product code retrieval methods, consider environmental constraints, performance requirements, and risk tolerance comprehensively. For most scenarios, the PowerShell COM interface solution is recommended as the primary choice, ensuring performance while minimizing system risks. In critical production environments, verify the suitability of selected methods in test systems first to ensure no impact on business operations.

Copyright Notice: All rights in this article are reserved by the operators of DevGex. Reasonable sharing and citation are welcome; any reproduction, excerpting, or re-publication without prior permission is prohibited.