Software Deployment

Properties passed on the command line are ignored when using the /f family of switches. You can get around this limitation by using the REINSTALL and REINSTALLMODE properties combined with the /i switch.

Off the top of my head, you'll want to do msiexec.exe /i <productcode> REINSTALL=all REINSTALLMODE=ou REBOOT=ReallySuppress /qn

The REINSTALLMODE property corresponds to whatever additional switches you want to use with /f.

Hi all,

I hope will be much better if we will use /fup...

Based off of MSDN the p switch is "Reinstalls only if file is missing."

Also, should I be setting keypaths for HKCU keys?

If your re-running of MSIExec is causing a reboot, I'd venture that your Current User feature in the feature tree contains a component which is triggering it. It has no place being there (obviously) so fix that first. As ever, MSI logging will help.

All I have added is 2 new components to a Transform. One component is for the Active Setup and the other is for the HKCU keys. I wouldn't think there is anything to fix, or is there?

Fair enough. What do I know?

msiexec.exe /i <productcode> REINSTALL=all REINSTALLMODE=ou REBOOT=ReallySuppress /qn

Might sound like a silly question, do I need both public properties together? REINSTALL=all REINSTALLMODE=ou

Test it!

I believe so though, REINSTALLMODE should be ignored if REINSTALL is not set.

Good catch, Joe. However, this isn't really helping the learning process. Rather than working around the issue, the OP would do better to find out why on earth user profile junk is triggering a reboot.

I prefer to think of it as working around the limitations of the msiexec engine, and in this line of work, dealing with the limitations of msiexec IS the learning process. Also, sometimes trying to dig into a vendor supplied MSI, especially if it was built with the opposite tool, is an exercise in futility. I'm assuming this guy is dealing with a crappy package that he didn't create, but that may be me having way too much faith.

I think we've lost sight of the problem, viz. exactly what, in the name of all that's holy, would cause a reboot in connection with user profile components?

Add REBOOT=r in the property table with the .mst?

dreyer,

Do you mean REBOOT=ReallySuppress?

VBScab and JSaylor,

I am attaching pieces from the log during repair.


00558: (Server): MSI (s) (4C:E0) [09:35:13:843]: Doing action: RebootConditionCheck
00559: (Unknown): Action ended 9:35:13: DetectOutlookUpgrade. Return value 1.
00560: (Server): MSI (s) (4C:E0) [09:35:13:843]: Note: 1: 2235 2: 3: ExtendedType 4: SELECT `Action`,`Type`,`Source`,`Target`, NULL, `ExtendedType` FROM `CustomAction` WHERE `Action` = 'RebootConditionCheck'
00561: (Server): MSI (s) (4C:DC) [09:35:13:859]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSIA.tmp, Entrypoint: RebootConditionCheck
00562: (Server): MSI (s) (4C!48) [09:35:13:921]: PROPERTY CHANGE: Adding REBOOT property. Its value is 'Forced'.
00563: (Unknown): Action start 9:35:13: RebootConditionCheck.
00564: (Server): MSI (s) (4C:E0) [09:35:13:921]: Doing action: RemoveExistingProducts
00565: (Unknown): Action ended 9:35:13: RebootConditionCheck. Return value 1.



06091: (Property): Property(S): REBOOT = Forced



06149: (Server): MSI (s) (4C:E0) [09:35:26:218]: Value of RebootAction property is
06150: (Server): MSI (s) (4C:E0) [09:35:26:218]: Windows Installer requires a system restart. Product Name: Livelink Explorer Professional 4.8.6. Product Version: 4.8.6. Product Language: 1033. Type of System Restart: 1. Reason for Restart: 0.
06151: (Unknown):



Do you mean REBOOT=ReallySuppress?For this property, everything after the first letter is ignored so 'R' is the same as 'ReallySuppress', 'S' = 'Suppress' and so on.

I wonder if this06091: (Property): Property(S): REBOOT = Forcedcould be the problem?!? It *looks* like the CA RebootConditionCheck is changing that property. Condition the CA so that it doesn't run for anything other than an install.

Actually, it would be worth investigating why the package needs a reboot at all. There are only a limited set of circumstances which absolutely require one. Most others can be worked around.

Woah there Ian, I'll have none of your "reading logs" shenanigans in this thread.

To look a little more closely, the REBOOT property is added just before RebootconditionCheck is started, so it might be a result of "DetectOutlookUpgrade" as well, you may wish to disable those CA's independently to figure out which one exactly is causing the property change.

For once, I did actually read the log so have to disagree. :-)

DetectOutlookUpgrade has already completed - it has returned value '1' - on the line before RebootConditionCheck is invoked.

how exactly did your stubpath command look when you added the reboot options? Also if you're only looking to propagate HKCU keys, you should stick to /fu imo

I tried the following.

"[SystemFolder]msiexec.exe /fou [ProductCode] /norestart /qn"

"[SystemFolder]msiexec.exe /fou [ProductCode] REBOOT=ReallySuppress /qn"

And yes you are right about the /fu switch rather than /fou. I added that in by mistake. I could have sworn I seen a post about people talking about this but I can't seem to find it anywhere.

Thanks for your help