The MSI doesn't repair when the install source is removed from its original location. How can it be fixed?
Here's the scenario:
1. Install the MSI (Having compressed/uncompressed files at its side).
2. Remove the source from its location on the machine.
3. Logoff/login.
4. The active setup runs (with switches /fup). But the repair fails with following prompt. It goes looking for the original source from where it was installed.
Isn't the installer supposed to go and look for it in the "%Windir%\installer" folder. It doesn't, which means I am wrong. Is there something to do with the SOURCELIST property? Please suggest, how can it be fixed.
Also, this doesn't happen when I try to repair only the registry keys .i.e with /fu.
Any help will be greatly appreciated!!
Thanks in advance!!!
1 Comment
[ + ] Show comment
-
Thanks EdT and Badger!!! While EdT shed some good light on the concept, Badger gave a possible solution to my current problem...marjing the question as answered. - mmudre@yahoo.com 9 years ago
Answers (2)
Answer Summary:
Please log in to answer
Posted by:
Badger
9 years ago
if you have moved it to a diff location (not just the cache has gone)
you can run (manually invoke, not an automatic repair)
msiexec /fomusv "full path to the new_Location of the .MSI" /qn
the v will force it to recache itself from the new location.
Posted by:
EdT
9 years ago
Repair takes place at a feature level, so if the resource being repaired is a file, then the original source must be available as the locally cached copy of the MSI in the c:\windows\installer folder DOES NOT INCLUDE the internal or external CAB files. Registry fixes work, since Windows Installer V2, because the registry keys are in the registry table, which is available in the locally cached MSI.
With the arrival of Windows Installer V5, the entire MSI is cached locally, including the files, so that uninstalls don't fail due to the signing of the MSI being damaged by the removal of internal CAB streams. However, due to a lack of joined up thinking, Microsoft did not adjust their software to use this local source for repair purposes.
To get around this, I documented a workaround which you can find here:
https://www-secure.symantec.com/connect/articles/reducing-windows-installer-disk-wastage-windows-7
Comments:
-
Hello Ed. I went through the link. From what I perceived, we can never get the repair to work if the source files are removed from their original location.
The scenario in our environment is that only the numbered MSI in Installer folder will be available for repair purposes, in which case we can never get the installer to repair our products.
Correct me if I am wrong. - mmudre@yahoo.com 9 years ago-
Wrong. See below - EdT 9 years ago
-
Also, I don't get why the installer goes looking for the original source files, when the registry (mentioned in the article) already has the path to the numbered MSI.
Is their any other registry, which can be tweaked to force the installer to go looking for the source for the numbered MSI during repair? in which case at least the products with internal cab files can be successfully repaired without the original source? - mmudre@yahoo.com 9 years ago-
Please go back and read my original reply carefully. You will see that the locally cached MSI (the numbered MSI as you call it), DOES NOT contain any internal or external CAB files so there are no sources to work with for healing. Therefore there is no point trying to use the local MSI as it cannot repair missing files.
My article refers to WIn 7 onwards where the entire MSI is cached but is still not available for repair due to some really stupid reason that Microsoft have never disclosed to my knowledge. - EdT 9 years ago
