To totally unlock this section you demand to Log-in

The product lawmaking is the unique GUID of identifying an application or production release; In other words, unlike versions and languages of Product must have different product codes.

Likewise, ProductCode can be used to query feature land, and product state. For example, installer API "MsiQueryFeatureStateEx()" and "MsiQueryProductState()", etc.

The following iv approaches can requite us several methods to find and call up (besides remotely) the GUID of installed MSI packages:

Use the Powershell "one-liner"

Any self-repair triggered by this option should generally be possible to cancel. The packet integrity checks triggered does add some consequence log "racket" though. Accept not that IdentifyingNumber is the ProductCode (WMI peculiarity).

go-wmiobject Win32_Product | Format-Table IdentifyingNumber, Name, LocalPackage -AutoSize

Quick showtime of Powershell: hold Windows central, tap R, type in "powershell" and press Enter.

Use VBScript

This choice may be safer than Powershell for reasons explained in detail below.

In essence it is (much) faster and not capable of triggering MSI cocky-repair since it does non become through WMI (it accesses the MSI COM API directly - at blistering speed). All the same, it is more than involved than the Powershell selection (several lines of code).

You tin can endeavour a VBScript to access information via the MSI automation interface (core feature of Windows - it is unrelated to WMI).

  • Copy the below script and paste into a *.vbs file on your desktop, and try to run it by double clicking. Your desktop must exist writable for you, or you can utilise any other writable location.
  • This is a sample VBScript. Terseness has been preferred over error handling and completeness, but it should do the task with minimum complexity.
  • The output file is created in the folder where you lot run the script from (folder must be writable). The output file is called msiinfo.csv.
  • Double click the file to open in a spreadsheet awarding, select comma every bit delimiter on import - OR - just open the file in Notepad or any text viewer. Opening in a spreadsheet will allow advanced sorting features.
  • This script tin easily be adapted to bear witness a significant amount of farther details about the MSI installation.
'#### Recollect all ProductCodes (with ProductName and ProductVersion) Set fso = CreateObject("Scripting.FileSystemObject") Set up output = fso.CreateTextFile("msiinfo.csv", True, True) Fix installer = CreateObject("WindowsInstaller.Installer")  On Error Resume Adjacent ' we ignore all errors  For Each product In installer.ProductsEx("", "", 7)    productcode = production.ProductCode    proper noun = product.InstallProperty("ProductName")    version=production.InstallProperty("VersionString")    output.writeline (productcode & ", " & proper name & ", " & version) Side by side  output.Close

Registry Lookup

You can also find the production code by perusing the registry from this base key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall.

Press F3 key and search for your product name. If it's a 32-bit installer on a 64-flake motorcar, it might be nether the following key: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall.

The following registry keys are the mutual locations in which search and detect the GUIDs of MSI packages:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall HKCU\Software\Microsoft\Windows\CurrentVersion\Uninstall

Original MSI File

You can discover the Production Code in the Property table of whatever MSI file (and any other property as well). However, the GUID could conceivably (rarely) be overridden by a transform practical at install fourth dimension and hence non lucifer the GUID the production is registered under (approach one and ii above will report the real product code - that is registered with Windows - in such rare scenarios).

You need a tool to view MSI files. See towards the bottom of the following answer for a listing of free tools you tin can download (or see quick selection below): How can I compare the content of two (or more) MSI files?

For convenience and need for speed, yous can download SuperOrca without delay and fuss from this direct-download hotlink - the tool is skillful enough to get the job washed - install, open MSI and get straight to the Holding tabular array and find the ProductCode row (please always virus cheque a direct-download hotlink - obviously - you can use virustotal.com to practice so - online browse utilizing dozens of anti-virus and malware suites to scan what you upload).

Another, the original, tool Orca is Microsoft's ain tool, it is installed with Visual Studio and the Windows SDK. Try searching for Orca-x86_en-us.msi, under Program Files (x86) and install the MSI if found.

Remember Product Codes

Fire upward Powershell (hold downwardly the Windows fundamental, tap R, release the Windows key, blazon in "powershell" and printing OK) and run the control below to become a list of installed MSI package product codes along with the local enshroud package path and the product name (maximize the PowerShell window to avoid truncated names).

Before running this command line, delight read the disclaimer below (goose egg unsafe, just some potential nuisances). If y'all are trying to uninstall a parcel there is a section below with some sample msiexec.exe command lines:

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

The output should be like to this:

Powershell - Check and find the product GUID of an installed MSI setup

For some foreign reason the "ProductCode" is referred to as "IdentifyingNumber" in WMI. So in other words, in the picture show above the IdentifyingNumber is the ProductCode.

Due to strange Microsoft blueprint, whatever WMI call to Win32_Product (like the PowerShell command beneath) will trigger a validation of the package manor. Besides existence quite slow, this can in rare cases trigger an MSI self-repair. This can exist a modest package or something huge - like Visual Studio. In nearly cases this does not happen, merely there is a take a chance.

Don't run this command right before an of import coming together, information technology is non e'er dangerous (it is a read-only query), merely it might lead to a long repair in very rare cases.

You tin can besides get the output in list form (instead of table):

get-wmiobject -course Win32_Product

In this case the output is similar to this:

Powershell - Check and find the product GUID of an installed MSI setup

Remember Production Codes From A Remote Estimator

In theory you should just be able to specify a remote computer name every bit part of the command itself. Here is the same command every bit above set up up to run on the motorcar "RemoteMachine" (-ComputerName RemoteMachine section added):

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

This might work if you lot are running with domain admin rights on a proper domain. In a workgroup surround (pocket-sized role / home network), you probably have to add user credentials directly to the WMI calls to brand it piece of work.

Additionally, remote connections in WMI are affected past (at to the lowest degree) the Windows Firewall, DCOM settings, and User Business relationship Command (UAC) (plus whatever additional non-Microsoft factors, for instance additional physical or virtual firewalls, third political party software firewalls, security software of diverse kinds, etc.). Whether information technology will work or not depends, usually, on your exact setup.

Powershell

PowerShell requires the .NET framework to be installed, but on most modern OSes (Windows Server and Windows platforms, Powershell is already included and available). The actual PowerShell awarding itself can besides be missing from the machine even if .Net is installed. Finally, PowerShell could be disabled or locked past various organisation policies and privileges.

If this is the example, you tin try a few other ways to retrieve production codes. An alternative is VBScript - it is fast and flexible (simply tin can also be locked on certain machines, and scripting is ever a piffling more than involved than using tools).

Allow'southward outset with a built-in Windows WMI tool, unremarkably used for testing WMI components and functionalities: wbemtest.exe.

  • Launch wbemtest.exe (Hold downwardly the Windows key, tap R, release the Windows cardinal, type in "wbemtest.exe" and printing OK).
  • Click connect then OK (namespace defaults to root\cimv2), and click "connect" again.
  • Click "Query" and type in this WQL control (SQL flavor): SELECT IdentifyingNumber,Name,Version FROM Win32_Product.
  • Click "Use" (or equivalent - the tool volition exist localized).

Sample output screenshot is the following. Non the nicest formatting, but you can go the data yous demand. IdentifyingNumber is the MSI product code:

Powershell - Check and find the product GUID of an installed MSI setup

Next, you can try a custom, more full featured WMI tool such as WMIExplorer.exe.

  • This is non included in Windows. It is a very good tool, however.
  • Check it out at: https://github.com/vinaypamnani/wmie2/releases.
  • Launch the tool, click Connect, double click ROOT\CIMV2
  • From the "Query tab", type in the post-obit query SELECT IdentifyingNumber,Proper name,Version FROM Win32_Product and printing Execute.

Get MSI Packages GUID (Comparing ProductCode and UpgradeCode)

Launch PowerShell: concur down the Windows and R key together, release the Windows key, blazon in "powershell" and printing OK or hit Enter.

Copy the script beneath in its entirety, and and so just correct click inside the PowerShell window.

For Win32_Property we filter both rows and columns (UpgradeCode is simply one of many row-types). Be prepared for a tedious performance, WMI is very slow doing such retrieves.

$wmipackages = Become-WmiObject -Class win32_product $wmiproperties = gwmi -Query "SELECT ProductCode,Value FROM Win32_Property WHERE Property='UpgradeCode'" $packageinfo = New-Object Organization.Data.Datatable  [void]$packageinfo.Columns.Add("Name") [void]$packageinfo.Columns.Add("ProductCode") [void]$packageinfo.Columns.Add together("UpgradeCode")  foreach ($parcel in $wmipackages)  {     $foundupgradecode = $false    #Let'south assume that no UpgradeCode is found all the same.      foreach ($holding in $wmiproperties) {          if ($bundle.IdentifyingNumber -eq $property.ProductCode) {            [void]$packageinfo.Rows.Add together($package.Name,$package.IdentifyingNumber, $property.Value)            $foundupgradecode = $true            interruption         }     }      if(-Non ($foundupgradecode)) {           # No upgrade code plant, add product code to list.          [void]$packageinfo.Rows.Add together($package.Name,$package.IdentifyingNumber, "")      }  }  $packageinfo | Format-table ProductCode, UpgradeCode, Name  # Enable the following line to consign to CSV (proficient for annotation). Set up full path in quotes. # $packageinfo | Export-Csv "[YourFullWriteablePath]\MsiInfo.csv"

The upgrade lawmaking is the unique GUID of identifying a family of a production. That is, the same products with different versions accept probably been shipped for a few releases. These products take dissimilar ProductCodes, only they are linked together past using SAME UpgradeCode.

For example, assuming that we wrote a product called "Happy MSI" and this product but has 1 MSI package for deployment on client system.

The outset release of this product is actually the MSI package with proper noun "version_1.msi", and the 2nd release is "version_2.msi". Then, these ii MSI must take same UpgradeCode. When users run "version_2.msi" on their system, the windows installer will use the UpgradeCode to decide if previous versions of this product are already present on the organization.

Installer API "MsiEnumRelatedProducts()" uses the UpgradeCode to query all the family products.

Uninstall MSI Packages

If what you lot desire to practise is to uninstall the MSI package and y'all constitute the product code (GUID) for, you can practise this equally follows using an elevated control prompt (search for cmd.exe, right click and run every bit admin):

Option 1: Basic, interactive uninstall without logging (quick and easy):

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

Quick Parameter Explanation:

  • /X = run uninstall sequence
  • {00000000-0000-0000-0000-00000000000C} = Production code for product to uninstall

You tin besides enable (verbose) logging and run in silent mode if you want to, leading us to selection 2:

Option 2: silent uninstall with verbose logging (better for batch files):

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

Quick Parameter Caption:

  • /X = run uninstall sequence
  • {00000000-0000-0000-0000-00000000000C} = Product code for product to uninstall
  • /QN = Run completely silently
  • /L*V "C:\My.log" = Verbose logging at specified path
  • REBOOT=ReallySuppress = Avert unexpected, sudden reboot