Disable Selfrepair after Installation
Hi everyone!
I've the following question: Does anyone of you know how to disable selfrepair on a specific component after the product has already been installed? My problem is that Adobe Acrobat 6.0 caues a selfrepair of the hp scanjet 4500c/5550c software because it renames the file TWUNK16.EXE in the winroot Directory to twunk16_exe.disabled and uses its own TWUNK16.EXE to scan the document. Then it calls the scanjet software which checks the components keypaths under the entrypoint feature and TWUNK16.EXE is the keypath of a component called PenguinMM(according to the eventlog). I tried to delete the keypath in the cached .msi under winroot\installer, but that didn't help so I guess the information is stored somewhere else. Of course I could change the original .msi on the installation point and reinstall the software, but I would like to know if anyone knows a better way to solve this problem!
thx
I've the following question: Does anyone of you know how to disable selfrepair on a specific component after the product has already been installed? My problem is that Adobe Acrobat 6.0 caues a selfrepair of the hp scanjet 4500c/5550c software because it renames the file TWUNK16.EXE in the winroot Directory to twunk16_exe.disabled and uses its own TWUNK16.EXE to scan the document. Then it calls the scanjet software which checks the components keypaths under the entrypoint feature and TWUNK16.EXE is the keypath of a component called PenguinMM(according to the eventlog). I tried to delete the keypath in the cached .msi under winroot\installer, but that didn't help so I guess the information is stored somewhere else. Of course I could change the original .msi on the installation point and reinstall the software, but I would like to know if anyone knows a better way to solve this problem!
thx
0 Comments
[ + ] Show comments
Answers (1)
Please log in to answer
Posted by:
VikingLoki
19 years ago
Looks like you found out exactly why Conflict Resolution is a part of creating packages. You have two MSI packages in a slugfest over a file, a.k.a a file conflict.
First, never attempt to manually change an installed MSI. That's as productive as swimming upstream. MSI on, MSI off. No MSI tweak. (Sorry, I'm in an odd mood) Seriously...
Here are your options:
1) Turn off self repair - Modify both MSIs so that TWUNK16.exe is not the key file to the component it's in. The downside to this is if something mucks up TWUNK16.EXE, both apps will break and not self repair. You also must uninstall & reinstall both packages on all machines.
2) Pick a TWUNK - Figure out which version of TWUNK16.EXE that you want to use. (That's usually the newer one) In the app that doesn't have the one you want, remove the old TWUNK16.EXE and replace it with the new one. See if the app works with the new TWUNK16.EXE. Now you only need to uninstall & reinstall the app where you replaced TWUNK.
2-A) If you have a lot installed already and the uninstall-reinstall is a big deal, you can put the new TWUNK16.EXE in an MSP patch. Either distribute the patch, or patch the admin install point and issue a command via MSIEXEC to reinstall from source. (as opposed to the cached msi)
First, never attempt to manually change an installed MSI. That's as productive as swimming upstream. MSI on, MSI off. No MSI tweak. (Sorry, I'm in an odd mood) Seriously...
Here are your options:
1) Turn off self repair - Modify both MSIs so that TWUNK16.exe is not the key file to the component it's in. The downside to this is if something mucks up TWUNK16.EXE, both apps will break and not self repair. You also must uninstall & reinstall both packages on all machines.
2) Pick a TWUNK - Figure out which version of TWUNK16.EXE that you want to use. (That's usually the newer one) In the app that doesn't have the one you want, remove the old TWUNK16.EXE and replace it with the new one. See if the app works with the new TWUNK16.EXE. Now you only need to uninstall & reinstall the app where you replaced TWUNK.
2-A) If you have a lot installed already and the uninstall-reinstall is a big deal, you can put the new TWUNK16.EXE in an MSP patch. Either distribute the patch, or patch the admin install point and issue a command via MSIEXEC to reinstall from source. (as opposed to the cached msi)
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.
