jjsather
asked on
"Per-user" install for new and old OS's
Our InstallShield setup has always installed "per-user," but we found it behaves differently in new OS's (Win7, Win8, Win Server 2008 and 2012) while it's fine in old OS's (WinXP, Vista, Win Server 2003). We'd like it to work on all OS's, though we are least concerned about XP.
The setup's ALLUSERS property is blank, which does a per-user on the old OS's. But in the new OS's, can install per-machine.
If I set ALLUSERS to 2, and MSIINSTALLPERUSER to 1, it installs per-user on new OS's, but now per-machine in old OS's. (This is because the old ones can't understand MSIINSTALLPERUSER due to old Windows Installers, so they only deal with ALLUSERS, and with that value, it does per-machine.)
How can our setup install "per-user" for all OS's?
The setup's ALLUSERS property is blank, which does a per-user on the old OS's. But in the new OS's, can install per-machine.
If I set ALLUSERS to 2, and MSIINSTALLPERUSER to 1, it installs per-user on new OS's, but now per-machine in old OS's. (This is because the old ones can't understand MSIINSTALLPERUSER due to old Windows Installers, so they only deal with ALLUSERS, and with that value, it does per-machine.)
How can our setup install "per-user" for all OS's?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
For some users, our software downloads its own updates, so it could selectively choose 1 of 2 setups, based on the OS. Or it could download the same setup and and pass switches. We could handle that scenario.
However, we also allow techs to download it directly, to later install to user's machines when they want. Those users could have different OS's, which is why it'd be nice to encapsulate the choice within the setup (or have properties within it that account for all OS's). But maybe that's not possible?
However, we also allow techs to download it directly, to later install to user's machines when they want. Those users could have different OS's, which is why it'd be nice to encapsulate the choice within the setup (or have properties within it that account for all OS's). But maybe that's not possible?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
InstallShield was finally able to give me the help needed. The answer required me to built various options into the setup with certain flags and conditional statements, outside of what was mentioned in this thread.
Can you post the details? This question will stay in E-E knowledge base, and it would be useful for the future visitors to know those flags and condition statements. Perhaps Installshield has its own KB about it?
ASKER
We've not fully tested the proposed solution (and can't for a while due to work conflicts) so hopefully this info is correct...
Set ALLUSERS=2 and MSIINSTALLPERUSER=1 in the project. As expected, this takes care of new machines.
Then in the "Custom Actions and Sequences", create a custom action that assigns ALLUSERS to a blank value. In that custom action, create the conditional statement "VersionNT<=600" in two places -- "Install UI Condition" and "Install Exec Condition" -- and for both, set their sequence values to "<First Action>". The idea is this will set ALLUSERS as needed for older machines, based off their VersionNT value in the chart below...
https://msdn.microsoft.com/en-us/library/aa370556%28v=vs.85%29.aspx
Set ALLUSERS=2 and MSIINSTALLPERUSER=1 in the project. As expected, this takes care of new machines.
Then in the "Custom Actions and Sequences", create a custom action that assigns ALLUSERS to a blank value. In that custom action, create the conditional statement "VersionNT<=600" in two places -- "Install UI Condition" and "Install Exec Condition" -- and for both, set their sequence values to "<First Action>". The idea is this will set ALLUSERS as needed for older machines, based off their VersionNT value in the chart below...
https://msdn.microsoft.com/en-us/library/aa370556%28v=vs.85%29.aspx
Thanks for clarification.
From my own experience, I can say that the efforts to tweak ALLUSERS within the installation historically had very bad results. Both Installshield and Wise Installer tried putting custom actions to this effect into the installation, in order to "fix" Installer, such as, for example, to handle situation when per-user installation runs on the machine where this product is already installed per-machine - and these efforts resulted in very extensive troubleshooting, if not at once, then in later versions of Installer and Windows. Note that when the MSI is deployed by group policy, Windows launches the installation with ALLUSERS parameter, depending on where in the group policy the MSI was. Changing that inside the installation has very big potential to interfere with the intent of GP.
This is just general comment, I did not try this specific scenario.
From my own experience, I can say that the efforts to tweak ALLUSERS within the installation historically had very bad results. Both Installshield and Wise Installer tried putting custom actions to this effect into the installation, in order to "fix" Installer, such as, for example, to handle situation when per-user installation runs on the machine where this product is already installed per-machine - and these efforts resulted in very extensive troubleshooting, if not at once, then in later versions of Installer and Windows. Note that when the MSI is deployed by group policy, Windows launches the installation with ALLUSERS parameter, depending on where in the group policy the MSI was. Changing that inside the installation has very big potential to interfere with the intent of GP.
This is just general comment, I did not try this specific scenario.
I actually tried to reproduce the problem. This sample installation (puts text file on the desktop) has neither ALLUSERS, nor MSIINSTALLPERUSER, and when launched manually, installed per-user on Windows XP and on Windows 8 for both admin- and non-admin-user. Perhaps question author's installation already had some tweaks of these properties that resulted in different behavior on different systems.
ASKER
So if you remove ALLUSERS, that's different than having it set to blank? That surprises me.
Blank is not the same as empty. Blank is just yet another string value, and since it's not a valid value for ALLUSERS, Installer fixes it during the installation, which you can see in the log:
MSI (s) (FC:EC) [06:26:51:924]: PROPERTY CHANGE: Modifying ALLUSERS property. Its current value is ' '. Its new value: '1'.
To have ALLUSERS as empty initially, the best way is to not create it at all. Note that it may be passed during installation launch as parameter (specifically, when launched by group policy), so manipulating it in the installation is a way to trouble.
MSI (s) (FC:EC) [06:26:51:924]: PROPERTY CHANGE: Modifying ALLUSERS property. Its current value is ' '. Its new value: '1'.
To have ALLUSERS as empty initially, the best way is to not create it at all. Note that it may be passed during installation launch as parameter (specifically, when launched by group policy), so manipulating it in the installation is a way to trouble.
ASKER
Sorry, but this is beyond my understanding. I don't know what you mean.
I was thinking along these lines. When our program calls the setup, I could sent switches. However, if the user runs the setup directly (which we also allow) then that won't work.
It'd be nice to just have the setup take the Version into account, and/or have flags in the setup to also force "per-user." But maybe that's not possible... or maybe you've both posted such solutions, but I'm just not understanding.