Scripting Question

Upgrade of MSI

03/10/2016 2993 views
I have one msi for which product code,upgrade code and package code are same with older version msi.
But ProductVersion is different.
Older: 70.2013.0212.0604
Newer: 71.2015.0815.0150

How to handle this situation with upgrade table.
When I tried with it, It is just reconfiguring the msi and at the msi log for FindRelatedProducts, I am getting below message.
MSI (s) (94:CC) [17:29:07:520]: Doing action: FindRelatedProducts
Action ended 17:29:07: AppSearch. Return value 0.
MSI (s) (94:CC) [17:29:07:520]: Skipping FindRelatedProducts action: not run in maintenance mode
0 Comments   [ + ] Show comments


Community Chosen Answer


No two MSI's should have the same package code. You need to change the package code first for performing an upgrade.

If the msi is going to perform some minor changes then you can perform a minor upgrade by changing the package code and version alone.

For types of upgrades have a look here - http://helpnet.flexerasoftware.com/installshield22helplib/helplibrary/MajorMinorSmall.htm


The FindRelatedProducts action only runs the first time the product is installed. It does not run during maintenance mode or uninstallation.

Maintenance mode means that the product is already installed which in your case is true, as defined by the ProductCode guid and the PackageCode guid.

The ALLUSERS value must be the same for two MSI's. A per-user install will not upgrade a per-machine install, and so vice versa.

Answered 03/10/2016 by: apptopack
Red Belt

  • This content is currently hidden from public view.
    Reason: Removed by member request For more information, visit our FAQ's.
  • Is there any alternate solution instead of changing the GUIDs?
    • Do a complete de-install of the older version, followed by a new installation of the new version... as they say in Germany, safety is safety...
    • If you dont want to change the GUID's then kindly follow Pressanykey and VBScab suggestions. It would be safe as older files will be completely uninstalled and newer one will be installed.

All Answers


Normally I'm not one for upgrading "in-place" in an enterprise environment, but rather de-install the older version, and then install the newer version. How ever, if I'm forced down this road, I make sure that remove existing products is very high in the sequence, so that previous versions are de-installed, then the new version installed. This should not cause any problems if the upgrade table is ok, however the package code being the same is very strange...
Perhaps VBScab could come out of retirement and say what he thinks...
Like I said, I do not like in-place updating / upgrading and avoid it like the plague...

Answered 03/10/2016 by: Pressanykey
Red Belt


>No two MSIs should have the same package code.
That sums it up.

As Phil says, to get around this, you should uninstall the old one then install the new. Once you're done with that, be sure to fire a missive to the brain-dead vendor about his useless packaging. You might want to offer your services, to ensure that no-one else has to work around their incompetence.

Answered 03/11/2016 by: VBScab
Red Belt

  • Previously we used to provide vbscript files to them where we will wireup this uninstallation and installation part of msis one after other.

    But with the arrival of SCCM 2012 Application Model, customers are asking not to provide these vbscripts and we came up with this package scenario through which upgrade table is not working as all the GUIDs are same except ProductVersion.

    Is there any alternate solution you can suggest to handle the previous version uninstallation in our msi itself.a
    • There is nothing wrong with using the same mechanism with SCCM. This provides a standard interface between deployment tool and package (i.e. the deployment tool always calls, for example install.vbs / remove.vbs / repair.vbs, and the script handles the package)

If you are supplying the MSI, then get that right.

Use the upgrade table properly. If you are changing the product version, its a new version (that sounds very funny)

When I have to do this on site, I create the new MSI to upgrade the old install by removing it.
If you install the new updated MSI on a clean machine, it just installs. If you install the new MSI on a machine with any of the old versions (assuming you know the UpgradeCodes and versions). That way you don't have to have multiple stringed MSI and then MSI upgrades.


I have been in your scenario with vendor supplied MSI's. They don't really know what they are doing with it, so I break the rules, change the PackageCode GUI directly, then sort out the upgrade stuff.

Yes thank you for the onslaught of replies now about how changing a vendor MSI will cause the world to spin backwards and thousands of fluffy bunnies to die somewhere.  However, if it is a vendor MSI and they cant get those 3 very important GUID correct, I doubt they are ever going to be bothered I have changed them. I am only changing the GUIDs no other actual logic in the MSI.

Answered 03/12/2016 by: Badger
Red Belt

  • A MSI is only a MSI if ti follows the rules... as soon as it breaks these rules, then it is no longer a MSI, ergo, you can do with it want you want. Regarding vendor support... poo, I say, poo... if you have to go as far as make major changes to a vendor supplied msi, what is their support worth? Hurrah for fluffy bunnies!
    • Not quite the attack i was expecting.
      Sometimes you get those people that read and remember ONE thing. NEVER directly change a vendor MSI. I agree with you. I normally say, when was the last time you contacted a vendor?? if you have, how helpful were they??
      Right, lets change that GUID.......

Don't be a Stranger!

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

Sign up! or login

View more:


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