Upgrade of MSI
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
Answers (4)
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
NOTE:
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.
Comments:
-
Is there any alternate solution instead of changing the GUIDs? - ur00361883 8 years ago
-
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... - Pressanykey 8 years ago
-
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. - apptopack 8 years ago
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...
Cheers
Phil
>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.
Comments:
-
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 - ur00361883 8 years ago-
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) - Pressanykey 8 years ago
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.
Comments:
-
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! - Pressanykey 8 years ago
-
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....... - Badger 8 years ago-
+1 - apptopack 8 years ago
