9 replies to this topic

[ori888]

Hello, 

 

I'm trying to create a basic MSI project which offers two types of installations:

1. For current user only (no admin-required changes in files and registry)

2. For all users (admin-required changes in registry and files). 

I set up two features accordingly, one install only for current user and the second for all user. The features need to meet a condition in order to be installed, the condition is a variable that the user sets in one of the dialogs. 

 

The features are being installed correctly and according to the user' choice. 

The problem is the 'Require Administrative Privileges' parameter in the 'General information tab' in Installshield ISM project. 

 

If it's set to 'Yes' then I also need administrator privileges in order to install the 'Current user installation', although it's not actually required and kind of missing the point of installing only for current user. 

If it's set to 'No' the installation fails for both types of installations (I get a message 'You do not have sufficient permissions…' from installshield. I would expect to get an UAC administrator prompt but I only get this error with no option to overcome it. 

 

How can I create a basic MSI that allows installing for all users (using admin user/prompt) OR installing only for current user (without using admin user/prompt)? 

 

Thank you,

Ori

 

 

[Glytzhkof]

I skimmed your question, bit busy right now. As a first step perhaps you can read this article: Authoring a single package for Per-User or Per-Machine Installation context in Window 7.

 

Windows Installer features "per-user setups" as an option controlled via the ALLUSERS property. Essentially the value of ALLUSERS and the user rights (whether the user has admin rights) allows redirecting of a bunch of data folders and shortcut locations. The exact details of this redirection is discussed here (referred to as Installation context).

 

I am not particularly fond of this per-user install concept - I find it conceptually flawed for many reasons, most significantly its poorly understood management and deployment implications: how do you upgrade an application that might be installed several times on the same computer for several users? What if you want to uninstall the application? When installing an update, does it apply for all other installations, or do you upgrade just for the current user?

 

You should also read Installshield's own documentation on ALLUSERS and Per-User vs. Per-Machine Installations, and perhaps glance at these two sources: itninja.com and symantec.com.

Edited by Glytzhkof, 16 September 2014 - 11:24.

[ori888]

Hi, 

 

Thank you for your quick and informative response.
I'm already updating the installation context by settings the ALLUSERS and MSIINSTALLPERUSER with the appropriate parameters but:

 

1. The installation still fails for per-user type in case the "Require Administrative privileges" is set to 'Yes' - it fails with "you do not have sufficient permission..." message and doesn't prompt for administrator.

It seems that the properties (allusers, msiinstallperuser) are not relevant - when the 'Require Admin privileges' is Yes then the user must be an administrator regardless of the installation type. Is this true?  

 

2. The installation still fails for all-users type in case the "Require Administrative privileges" is set to 'No'. It fails with "you do not have the sufficient permission..." message and doesn't prompt for administrator. 
It seems the all-users installation is not possible when the "Require Administrative privileges" is set to 'No'. Is this true? 

 

EDIT: These are the log messages that indicate that the installation sets the ALLUSERS + MSIINSTALLPERUSER properties for per-user installation but still prompt for administrator credentials (Require Admin privileges' is No):

MSI (s) (C0:BC) [12:07:53:685]: PROPERTY CHANGE: Modifying ALLUSERS property. Its current value is '0'. Its new value: '""'.

MSI (s) (C0:BC) [12:07:53:685]: PROPERTY CHANGE: Deleting MSIINSTALLPERUSER property. Its current value is '1'.

MSI (s) (C0:BC) [12:07:53:685]: Product {4FB5BC84-1519-4002-AA8A-18F1EAD9268E} is not managed.

MSI (s) (C0:BC) [12:07:53:685]: Machine policy value 'AlwaysInstallElevated' is 0

MSI (s) (C0:BC) [12:07:53:685]: User policy value 'AlwaysInstallElevated' is 0

MSI (s) (C0:BC) [12:07:53:685]: MSI_LUA: Elevation required to install product, will prompt for credentials

 

Regarding the need for this type of the installation architecture - my customer actually needs both types of installation in one MSI project. I expected it to work with much less effort. Regarding the uninstall/upgrade processes - I don't see it as a technical problem but rather product-related decisions I should make. 

 

Thank you again!
Ori

Edited by ori888, 21 September 2014 - 11:50.

[yonishec]

Hi,

 

I have encountered the same problem. Do we have any idea how to solve it?

 

Thanks,

Yoni

[Stefan Krueger]

Just a wild guess: did this work before Microsoft's August updates? KB2918614 is known to change the behaviour for updates. Maybe it also affects first time installs? (You could temporarily uninstall that update on a test machine)
 

[ori888]

Hi Stefan,

The machine i'm working with does not contain this update.

 

Thanks, 

Ori. 

[yonishec]

Hi, Stefan,

 

Thanks for the quick reply. I checked it also and this update isn't present.

Is there any information (such as logs) that I can provide and might help understand why this isn't working?

 

Thanks,

Yoni

[Glytzhkof]

Instead of using Installshield's setup.exe launcher logic, I would use a custom action in the MSI for requiring admin rights to install per-machine. It needs to determine if the user is administrator or not, and determine if the installation is being run per-user or per-machine. Note that Windows Installer will realign or set ALLUSERS depending on whether the user is administrator or not. Try to compile a compressed MSI and not one wrapped in a setup.exe. There has also been some issues with the manifest for the setup.exe not correctly identifying the required admin rights for the UAC, but that should not be an issue if you run the MSI directly.

Edited by Glytzhkof, 24 September 2014 - 11:24.

[yonishec]

Hi,

 

I don't use the setup.exe

My project is a basic MSI without setup.exe but only MSI

 

And the link you provided about the ALLUSER (and other stuff) is already implemented. Still, it doesn't work. What Ori mentioned in his comments is the same in my project.

 

Thanks,

Yoni

Edited by yonishec, 25 September 2014 - 07:13.

[yonishec]

Hi,

 

Does anyone have any idea how can we proceed with this issue?

 

Thanks,

Yoni