Shortcuts for ALLUSERS not working on silent installation

[Martin H.]

My setup is created as single msi file.
In MSICODE I set the variable ALLUSERS=TRUE as early as possible, because I always want to install for all users. I removed the dialog, including the selection "only for me"/"all users", from UI sequence.
When installing (my user has admin rights) the msi with user interaction (double clicking the msi and install it manually) it all works fine. This means my shortcuts are created for all users in path "C:\ProgramData\Microsoft\Windows\Start Menu\Programs".
But when starting setup in silent mode with command (console is opened with admin rights) "msiexec /i "c:\tmp\test.msi" /quiet /qn /norestart" the shortcuts are created in the roaming folder of the user who started the above command. Adding "ALLUSERS=TRUE" or "ALLUSERS=1" to the msiexec command takes no effekt. Why it behaves different?

[FrancescoT]

Without having your setup script code is quite difficult to answer your question.

At any rate and If you kept the default script logic, to force a PER-MACHINE installation, it's enough to set the variable ALLUSERS as TRUE at the very beginning of the main script file, and of course in such case, it will be also necessary to exclude from the setup sequence the the dialog which allows the selection "only for me"/"all users".

Alternatively to execute the silent installation from command line of the MSI package:
msiexec.exe /i "mypackage.msi" CMDLINE="ALLUSERS=TRUE /s"

[amolago]

Hi,

Was there ever any resolution to this. I've noticed this today when assessing what get installed when.

It's very easy to reproduce with the most basic script:

Set Variable ALLUSERS to TRUE
Write into Text File C:\Users\user\log.txt from Value CMDLINE=$CMDLINE$ (at end of file)
Write into Text File C:\Users\user\log.txt from Value ALLUSERS=$ALLUSERS$ (at end of file)

That's it

Then we see:
msiexec /i test.msi

type log.txt
CMDLINE="/g=C:\Users\user\" ALLUSERS=FALSE /m="C:\Users\user\AppData\Local\Temp\{48FC5~1.EXE" /k=""
ALLUSERS=TRUE

But:
msiexec /i test.msi /quiet

type log.txt
CMDLINE=/s "/g=C:\Users\user\" ALLUSERS=FALSE /m="C:\Users\user\AppData\Local\Temp\{48FC5~1.EXE" /k=""
ALLUSERS=FALSE

Which makes no sense! Why does 'ALLUSERS' not stick for silent setups?

[JohnGaver]

Great depth of reporting, thank you! This helps us easily understand what you're seeing happening.

Our core takeaway here is: Command line variable locking won't happen unless your setup is running silently, OR you're passing variables using the : (colon) operator instead of the = (equals) operator while running interactively (and/or silently).

So in your first example, you're able to set ALLUSERS to TRUE because setup is running non-silently. Variables aren't locked, they can be overridden in your setup script.

But in your second example, your Set Variable statement for ALLUSERS is being ignored by the setup engine. This is because setup is being run silently.

If setup did not ignore such statements while running silently, silent installations where, for example, you provide custom paths for things like TARGETDIR would become impossible - they would be overridden the moment your script calls Set Variable on TARGETDIR, which initializes it to C:\Program Files by default.

I hope this helps you understand the nature of the issue you are seeing.

Please note that ALLUSERS is managed internally - and might I add accurately - during Active Directory/Group Policy deployments, based on the *actual* mode of deployment selected by your system administrator - so this is kind of a false concern at best.

However if you wanted to, as mentioned in the Group Policy Wizard, you could either override the CMDLINE MSI variable when calling msiexec with whatever you like (including ALLUSERS=TRUE or ALLUSERS=FALSE, or even ALLUSERS:TRUE or ALLUSERS:FALSE inside the CMDLINE MSI variable), or you could inject those variable overrides in the Command Line Parameters field of the Group Policy Wizard to enforce a particular static value for your MSIs.

So if your workflow is still somehow not satisfied by automatic assignment of the ALLUSERS variable to its proper value during actual Active Directory/Group Policy deployments, you could still force it to whatever you like.

Please don't hesitate to let us know more about the actual workflow you're looking at for additional guidance!

[amolago]

Hi John,

Thanks for the update. I see what you're saying and it does make sense.

For me I was just starting to work through verifying what was installed and that the uninstallation removed it all. That's when I noticed the difference between UI and silent, notably:
* Shortcut location changed - I can easily fix this by ignoring the ALLUSERS property
* Unpacked location of the setup (c:\ProgramData\{xxx} vs c:\Users\user\AppData\Local\{xxx}
* Registry "Uninstall" location (HKLM\SOFTWARE\...\Uninstall\{xxx} vs HKCU\SOFTWARE\...\Uninstall\{xxx})

So I'm now just checking what if the user silently installs, then UI uninstalls, or vice versa.

Note, I did "hack" the MSI produced by IA to add the ALLUSERS=TRUE property, but now I can't uninstall (error: product not installed), so I'll be reverting that!

[JohnGaver]

Great of you to check, but yes, this is all our responsibility - and what you're paying us for - so there was really no need for you to have bothered with these verifications at all.

You're also correct that ALLUSERS must be internally managed - as you can see otherwise, it can cause problems. Sometimes we end up creating artificial problems while trying to verify and/or make things better.

The diligence and thoroughness you have shown in testing your install is going to be most appreciated by your end-users - as I'm sure you apply the same approach to other parts of your setup (and not just the plumbing that is InstallAware's responsibility), so congratulations! Your end-users are very fortunate indeed.

[amolago]

Hi John,

Haha, not sure about all that I'm having to try to uninstall a old WiX setup as part of the install/update which isn't working properly, hence the diligence!

Anyway, I now feel I should report then that shortcuts still don't appear to be quite as expected:

Code: Select all

Set Variable ALLUSERS to FALSE
Get Common Folder Location System->Application Data Directory into PROGRAM_DATA
Set Variable SHORTCUTFOLDER to $PROGRAM_DATA$\Microsoft\Windows\Start Menu\Programs\My Company\$TITLE$
Create Shortcut $SHORTCUTFOLDER$\My App to $TARGETDIR$\myapp.exe


From logging I can see that PROGRAM_DATA is indeed set to C:\ProgramData, but what I end up with on the system is:

Code: Select all

DIR /B /S "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\"
...
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\My Company\My Product


DIR /B /S "C:\Users\bob\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\"
...
C:\Users\bob\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\My Company\My Product
C:\Users\bob\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\My Company\My Product\My App.lnk


So it seems I cannot necessarily get the shortcut in to the C:\ProgramData directory, though I do get an empty folder.

[JohnGaver]

Oh yeah, WiX is, kind of the diametric opposite of heaven, from what I hear

Interesting issue you've got here. Doesn't seem to be related to the current discussion - rather looking like a case where a variable is not honoring its assigned value, perhaps?

I'd create a new issue/thread for this one, along with a minimum project - if at all possible - that just narrows this problem down for us here.

Could also be some kind of Microsoft file system virtualization/redirection in play as they do for some kinds of folders - would really love to find out more about this!