I am using active setup to populate some HKCU keys. I added the following registry information.


[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\[ProductName]]
"StubPath"="[SystemFolder]msiexec.exe /fou [ProductCode] /qn"@="[ProductName]"
"Locale"="EN"
"DontAsk"=dword:00000002
"ComponentID"="[ProductName]"
"IsInstalled"=dword:00000001
"Version"="1,0,0"


I tried adding /norestart and/or REBOOT=ReallySuppress into the stubpath command line but that information seems to be ignored and reboots anyways. Anyone have any suggestions?

Thanks,

Rob
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

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

Answers

0
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
Answered 10/20/2010 by: pjgeutjens
Red Belt

Please log in to comment
0
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
Answered 10/20/2010 by: mreusguy
Senior Yellow Belt

Please log in to comment
0
Hi all,

I hope will be much better if we will use /fup...
Answered 10/20/2010 by: SM
Senior Yellow Belt

Please log in to comment
0
Based off of MSDN the p switch is "Reinstalls only if file is missing."

Also, should I be setting keypaths for HKCU keys?
Answered 10/20/2010 by: mreusguy
Senior Yellow Belt

Please log in to comment
0
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.
Answered 10/20/2010 by: VBScab
Red Belt

Please log in to comment
0
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?
Answered 10/20/2010 by: mreusguy
Senior Yellow Belt

Please log in to comment
0
Fair enough. What do I know?
Answered 10/21/2010 by: VBScab
Red Belt

Please log in to comment
2
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.
Answered 10/21/2010 by: Jsaylor
Second Degree Blue Belt

Please log in to comment
0

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
Answered 10/21/2010 by: mreusguy
Senior Yellow Belt

Please log in to comment
0
Test it!

I believe so though, REINSTALLMODE should be ignored if REINSTALL is not set.
Answered 10/21/2010 by: Jsaylor
Second Degree Blue Belt

Please log in to comment
0
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.
Answered 10/22/2010 by: VBScab
Red Belt

Please log in to comment
0
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.
Answered 10/22/2010 by: Jsaylor
Second Degree Blue Belt

Please log in to comment
0
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?
Answered 10/24/2010 by: VBScab
Red Belt

Please log in to comment
0
Add REBOOT=r in the property table with the .mst?
Answered 10/25/2010 by: dreyer
Purple Belt

Please log in to comment
0
dreyer,

Do you mean REBOOT=ReallySuppress?
Answered 10/26/2010 by: mreusguy
Senior Yellow Belt

Please log in to comment
0
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):

Answered 10/26/2010 by: mreusguy
Senior Yellow Belt

Please log in to comment
0
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.
Answered 10/26/2010 by: VBScab
Red Belt

Please log in to comment
0
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.
Answered 10/26/2010 by: Jsaylor
Second Degree Blue Belt

Please log in to comment
0
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.
Answered 10/27/2010 by: VBScab
Red Belt

Please log in to comment
Answer this question or Comment on this question for clarity