/bundles/itninjaweb/img/Breadcrumb_cap_w.png

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.

Answer Summary:
1 Comment   [ + ] Show comment

Comments

  • 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.

Answer Chosen by the Author

1
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!
Answered 12/22/2016 by: rileyz
Red Belt

All Answers

1
...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.
Answered 12/23/2016 by: VBScab
Red Belt

1
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.
Answered 12/23/2016 by: EdT
Red Belt

0
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"


Answered 12/22/2016 by: pt_mih
White Belt