/build/static/layout/Breadcrumb_cap_w.png

Question about repair

Theoretical question.
If I run the msiexec /i on a pc on which the msi product is installed allready, does this equal the msiexec /fvemus command ?

0 Comments   [ + ] Show comments

Answers (6)

Posted by: pjgeutjens 11 years ago
Red Belt
0
If I run the msiexec /i on a pc on which the msi product is installed allready, does this equal the msiexec /fvemus command ?

well, assuming you choose to repair the installation after running the msiexec.exe command, this depends on the value of the REINSTALLMODE property. Its default value is omus, so no, it's not the same.

I do think you could say msiexec.exe /i REINSTALL=ALL REINSTALLMODE=fvemus would be the same.

PJ
Posted by: anonymous_9363 11 years ago
Red Belt
0
On its own, how can it? The command line you show would produce a UI and it will be up to the user to decide what happens, be that repair, modify or uninstall.
Posted by: ikke 11 years ago
Senior Purple Belt
0
@ pjgeutjens

The reason why I ask is because i need to repair a pacthed installation and the policy is that we impliment a msiexec /fvemus command in our wrappers to run when an msi is detected on a machines.

I cannot run msiexec /fvemus on the msi because the msi that is installed is patched.

However, I succeed in running msiexec /i <msiname> /p <patch> /qn successfully, when the msi was allready installed on the system.
So maybe I can modify the command line to msiexec /i <msiname> /p <patch> REINSTALL=ALL REINSTALLMODE=fvemus /qn

Maybe I can

@vbscab
We are adding a qn switch at the end as well.
Posted by: anonymous_9363 11 years ago
Red Belt
0
Surely an object lesson in NEVER patching clients directly? If you had patched an Administrative Installation Point and run your installs from there, the question would never have arisen.

Meanwhile, the machine knows that the installation has been patched and records the patch details in the registry. Therefore, provided the registry details are intact, one would just run the repair command as normal, leaving it to the WI engine to get the correct file(s).
Posted by: ikke 11 years ago
Senior Purple Belt
0
@vbscab.
But then the repair would run from the allready cached installation and the msi would not be recached ?
Or is this a wrong assumption ?
Posted by: yeah yeah 11 years ago
Senior Yellow Belt
0
Question. I pushed out an install to my enterprise via SMS to update everyone from Acrobat 8.2.2 to 8.2.3. There are some workstations that may have had Acrobat opened, so the Acrobat.exe and one of the .dll files remained at the 8.2.2 version, while the rest of the files were updated correctly. The install also shows that the installation was done successfully. Our vulnerability scans that we run of course checks the version of acrobat.exe and the .dll. Since that shows lower than 8.2.3, then the machine shows as a vulnerability. I was able to correct the SMS package on later installs (to kill Acrobat.exe process from running, then install...), but now I need to send a remote repair. I know if I SMS into the machine, run a repair from Add/Remove, it will correct itself. How can I do this remotely? I used this to install:

MsiExec.exe /p AcrobatUpd823_all.msp REINSTALLMODE=omus REINSTALL=ALL /qn REBOOT=Suppress

I know in some cases, I can copy the MSP file to the machine, then psexec in, and rerun it, but that's way too much work since a simple repair works.

Thoughts?
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Don't be a Stranger!

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

Sign up! or login

Share

 
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