"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?
jjsatherAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Vadim RappCommented:
How about publishing it in the group policy under User Configuration? That should force per-user when it's launched.
0
arnoldCommented:
You would need to use two installers in separate GPOs that will use wmi filter as the mechanism to distinguish between/among the systems such that one will apply to the old, while the other will apply to the newer
OS version <=6 old
>= 7 new.

You've already isolated the issue.
The other option is to use a batch wrapper that will determine which OS is being used on the system running it and will call/run the appropriate set of options.

Presumably the difference in the options are part of the msiexec version, you could try updating the installer from 2,3 to 4.5 and see if that helps harmonize the install behavior.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
jjsatherAuthor Commented:
How about publishing it in the group policy under User Configuration? That should force per-user when it's launched.
I'm afraid I don't know what the means. I'm not real familiar with setups and am learning as I go here.

You would need to use two installers in separate GPOs that will use wmi filter...
Sorry, but this is beyond my understanding. I don't know what you mean.

The other option is to use a batch wrapper that will determine which OS is being used on the system running it and will call/run the appropriate set of options.
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.
0
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

arnoldCommented:
what options are available to you?
One deals with auto-installing /deploying the software using a GPO (GPMC) is a tool.
0
jjsatherAuthor Commented:
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?
0
arnoldCommented:
Do you build the package, or does it come from a vendor, If you build the package, you could include detection within or if the option allows i.e. if it is an .msi package, see if /a option is available. this at times have an option to include an answer file ...

Have you considered the auto-deployment of software via GPO?  Presumably, the techs have to get involved because the user lacks the rights on the newer system to install.

If techs are doing the install, it should be simple enough to advise them to use the new instal.bat file versus the setup.exe or package.msi
in install.bat or powershell that will check the OS version and will set the parameters as needed before executing.
0
Vadim RappCommented:
> I'm afraid I don't know what the means. I'm not real familiar with setups and am learning as I go here.

There's quite a few articles.
0
jjsatherAuthor Commented:
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.
0
Vadim RappCommented:
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?
0
jjsatherAuthor Commented:
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
0
Vadim RappCommented:
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.
0
Vadim RappCommented:
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.
0
jjsatherAuthor Commented:
So if you remove ALLUSERS, that's different than having it set to blank? That surprises me.
0
Vadim RappCommented:
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.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2008

From novice to tech pro — start learning today.