Upgrading an MSI with same product code and Upgrade code

I have an application B with version 12.10, there is an older version of this application i.e 11.20, with the same product code and Upgrade code. while deploying in SCCM I created 2 deployment types

1) Installation of my 12.10 version MSI and MST

2) VBScript to Uninstall the older version (11.20) and added this as the dependency for step 1 installation.

So while testing the application, the older version is removed, but failed to install the current version.

I tried using the upgrade code in Upgrade table in MST, that dint work for me. Also added Custom action to remove older version, that too failed.

Could someone please help me with a VB script to detect the previous version is present and uninstall it and install the current version.

Kindly help in this case.

Thanks in advance.

1 Comment   [ + ] Show comment
  • Since, it is a major upgrade, you might need to change the ProductCode of your latest msi (12.10). PackageCode also needs to be changed if it is same. - jagadeish 4 years ago

Answers (4)

Answer Summary:
Posted by: rileyz 4 years ago
Red Belt

Top Answer

Dont listen to pt_mih, you never change the PRODUCTCODE of a vendor MSI - it breaks a fundamental rule in packaging. Is this a vendor MSI or inhouse authored MSI?

Anyway you're on the right track, you need to added the info to the UPGRADE table, and then move around the REMOVEEXISTINGPRODUCTS in the InstallExecute sequence so it removes old product before installing the new product - sorry I haven't worked with MSI's for about a year so my msi foo is a bit crap at the moment.

Dont use a CustomAction (in VB) to uninstall Product A - use the inbuilt tools provided by Windows Installer.

That a side, your plan should of worked with the dependency to remove Product A before installing Product B. Enable full logging with by appending this switch to your install command /l*vx c:\SomeFolder\ProductB.log. That way you can debug the issue, it might need a reboot or something? Anyway everything will be in the logs, it would be helpful if you could provide the error next time.

Good luck!
Posted by: anonymous_9363 4 years ago
Red Belt
...and when you're done, be sure to send the vendor a link to the relevant page on MSDN which deals with ProductCode and UpgradeCode usage since they clearly have no clue.
Posted by: pt_mih 4 years ago
White Belt
Changing the product code in the new version should enable Windows Installer to do its automatic upgrade work (no need to add the upgrade code in the Upgrade table).

AFAIK VB scripts run asynchronously so the install process won't wait for the uninstall process to finish. You could use delay method but that can get messy and I personally don't find it very elegant.

Try a BAT file instead:
%WINDIR%\system32\msiexec /x {PRODUCT_CODE} /qb
%WINDIR%\system32\msiexec /i "Your Application 12.10.msi"

Posted by: EdT 4 years ago
Red Belt
The simplest way is to follow normal upgrade procedures. The UpgradeCode is usually unchanged for a product series as it goes through minor upgrades although I would personally expect a change in version from 11.xx to 12.xx to count as a major upgrade, but it's not cast in stone. 
Equally, the ProductCode does not have to change for minor upgrades but I would agree that it's bad practice not to change this for a major upgrade. Still, it's also not cast in concrete.
The one thing that definitely HAS to change between two non-identical MSI installs is the PackageCode.
Aside from that, a minor upgrade will also see the ProductVersion field change and this change needs to be reflected in the Upgrade Table.   Any new action properties should also be added to the securecustomproperties list in the Property table.
The RemoveExistingProducts action needs to be between InstallValidate and InstallInitalize in the InstallExecute sequence, to ensure that the old MSI gets removed entirely before the new MSI is installed.  You don't need the hassle of running VBScripts or batch files to remove and install unless the removal is so unreliable or leaves crap behind, making the native uninstall unworkable. That would be the sign of a totally unprofessional installer and would be worthy of some piss taking in the vendor forums.

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login


This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ