This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Per User vs Per Machine Using ALLUSERS/MISINSTALLPERUSER
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 27, 2015
12:09 PM
Per User vs Per Machine Using ALLUSERS/MISINSTALLPERUSER
Hi all,
For years our company struggled with a per user-per machine install and application marriage. If used to be that the install and the app accessed 'stuff' in both machine and user locations. Accessing the user locations caused repair installs to occur when non-installing users would attempt to use the software. This was not seen as favorable by end users as it basically freaked them out.
So, through the years we've whittled away at the install to make it strictly a per machine process, which as we all know required Admin rights for installation. This is now seen as unfavorable for deployment. I know we have a choice, either per machine or per user and the two really shouldn't be mixed. I also know that with recent versions of Windows Installer we can create dual role packages that, buy utilizing ALLUSERS/MSIINSTALLPERUSER properties, can handle file redirection, etc.
I guess I'll start investigating that option, but I would like to know what should the requirements be for the actual application. I would like to be able to present our development teams some best practices to follow if there desire is per user. Should the app not write to HKLM or protected file system areas at runtime? Should I just ignore the functionality of the app and deal with the install only in handling placement to user area or should the app simply fall in line with application requirements.
I'm not sure if makes sense to have a per user capable install for an app that may require elevation.
If anyone can help forge a path and determine which is the best starting point that would be great!!
For years our company struggled with a per user-per machine install and application marriage. If used to be that the install and the app accessed 'stuff' in both machine and user locations. Accessing the user locations caused repair installs to occur when non-installing users would attempt to use the software. This was not seen as favorable by end users as it basically freaked them out.
So, through the years we've whittled away at the install to make it strictly a per machine process, which as we all know required Admin rights for installation. This is now seen as unfavorable for deployment. I know we have a choice, either per machine or per user and the two really shouldn't be mixed. I also know that with recent versions of Windows Installer we can create dual role packages that, buy utilizing ALLUSERS/MSIINSTALLPERUSER properties, can handle file redirection, etc.
I guess I'll start investigating that option, but I would like to know what should the requirements be for the actual application. I would like to be able to present our development teams some best practices to follow if there desire is per user. Should the app not write to HKLM or protected file system areas at runtime? Should I just ignore the functionality of the app and deal with the install only in handling placement to user area or should the app simply fall in line with application requirements.
I'm not sure if makes sense to have a per user capable install for an app that may require elevation.
If anyone can help forge a path and determine which is the best starting point that would be great!!
(2) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 30, 2015
08:28 AM
In the general case, an elevating application is not the best candidate for a per-user installation, as some users can only elevate through over-the-shoulder scenarios that involve a different elevated user. In practice, the users who would use such an application are probably administrators themselves. So let's set that aside.
The requirements for non-elevated per-user applications in general are equivalent to those of non-elevated per-machine applications: it's okay to read templates and such from the installation location, but you have to write to per-user locations. For the scenarios you mention, if the previously per-user items were not modified, just read them from the installation location and it won't matter if it's per-user or per-machine. If they are modified by the user, cache them to a per-user location on first run of the application. Then it doesn't matter how it was installed, the items that are changed are always in per-user locations.
But do think about why you might require elevation today. Is it inherent to what your application is doing, or is it an artifact of where it's keeping its data? For an example of the first, InstallShield elevates to support COM Extraction, the mechanics of which require elevation. However the per-machine location where InstallShield keeps redistributables (by default) is an example of the second.
The requirements for non-elevated per-user applications in general are equivalent to those of non-elevated per-machine applications: it's okay to read templates and such from the installation location, but you have to write to per-user locations. For the scenarios you mention, if the previously per-user items were not modified, just read them from the installation location and it won't matter if it's per-user or per-machine. If they are modified by the user, cache them to a per-user location on first run of the application. Then it doesn't matter how it was installed, the items that are changed are always in per-user locations.
But do think about why you might require elevation today. Is it inherent to what your application is doing, or is it an artifact of where it's keeping its data? For an example of the first, InstallShield elevates to support COM Extraction, the mechanics of which require elevation. However the per-machine location where InstallShield keeps redistributables (by default) is an example of the second.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 30, 2015
08:52 AM
Thank you for the reply!!
I think most of the problem was that upon the advent of UAC, development never really took the time to understand how to play nice with the new security concept. Then never stopped to look into the why or does what we are doing actually require per machine locations, etc.
I'm thinking that if the App can reside in a user area and survive by only writing to/acting upon such locations we would be OK (stay away from Program Files as default, HKLM, Common App Data, etc). Then, the installation would be a piece of cake I think.
However, we are up against a major obstacle. We integrate with some third party apps which require us to place some things in HKLM, under their file system structure, etc I know that when setting ALLUSERS=2 and MSIINSTALLPERUSER=1 that we're set up for a per-user installation and such items would be redirected automatically to user areas. I don't know if that will sustain us in dealing with the third party requirements.
Thanks again for the reply. It's tough sometimes to get comments on inquiries such as these that aren't directly related to InstallShield.
I think most of the problem was that upon the advent of UAC, development never really took the time to understand how to play nice with the new security concept. Then never stopped to look into the why or does what we are doing actually require per machine locations, etc.
I'm thinking that if the App can reside in a user area and survive by only writing to/acting upon such locations we would be OK (stay away from Program Files as default, HKLM, Common App Data, etc). Then, the installation would be a piece of cake I think.
However, we are up against a major obstacle. We integrate with some third party apps which require us to place some things in HKLM, under their file system structure, etc I know that when setting ALLUSERS=2 and MSIINSTALLPERUSER=1 that we're set up for a per-user installation and such items would be redirected automatically to user areas. I don't know if that will sustain us in dealing with the third party requirements.
Thanks again for the reply. It's tough sometimes to get comments on inquiries such as these that aren't directly related to InstallShield.
