Rif.: Installer Admin priviledges

[michele.santucci]

There's a way to avoid installers created by the Application Builder to require elevated priviledges?

[GerdW]

Hi Michele,

as soon as you want to install any drivers you will need admin priviledges, so what's the problem?

[wiebe@CARYA]

I think InnoSetup can run it's tasks with elevated rights.

So you can wrap LabVIEW's installer in an InnoSetup intsaller. The installer would still need admin rights. Added benefit: you only have 1 installer file.

[rolfk]

---

wiebe@CARYA wrote:

I think InnoSetup can run it's tasks with elevated rights.

So you can wrap LabVIEW's installer in an InnoSetup intsaller. The installer would still need admin rights. Added benefit: you only have 1 installer file.

---

I might be misunderstanding the OP, but I think (s)he wants to NOT have the installer require Admin privileges. Generally this is not possible since an application is by default always installed under <Program Files> and that is a privileged location that normal users have no write access rights to. Windows automatically tends to assume that executables which are called setup.exe or similar do require elevation and will normally prompt the user with the UAC dialog for the according credentials.

[wiebe@CARYA]

---

@rolfk wrote:

---

wiebe@CARYA wrote:

I think InnoSetup can run it's tasks with elevated rights.

So you can wrap LabVIEW's installer in an InnoSetup intsaller. The installer would still need admin rights. Added benefit: you only have 1 installer file.

---

I might be misunderstanding the OP, but I think (s)he wants to NOT have the installer require Admin privileges. Generally this is not possible since an application is by default always installed under <Program Files> and that is a privileged location that normal users have no write access rights to. Windows automatically tends to assume that executables which are called setup.exe or similar do require elevation and will normally prompt the user with the UAC dialog for the according credentials.

---

OP asks for not needing elevated rights:

@michele.santucci wrote:

There's a way to avoid installers created by the Application Builder to require elevated priviledges?

---

Elevated rights is slightly different from admin rights. If a user has admin rights, (s)he still needs elevated rights to install in program files (I think).

IS might take the admin rights and elevate them. I'm not sure, I rarely run my own installers... NI's installer won't do that for sure.

My InnoSetup script also adds a few things to the command line when calling LV's Setup.exe. It does take switches so system administrators can install without popups.

[michele.santucci]

I expressed myself in the wrong way... in reality I think that the problem is due to an INCORRECT setting of the PC on which I am running the installation.
The installer that I am creating installs part of the files in the system folders (for which administrator privileges are necessary) but part of the remaining files must be installed in the user folders (C:\Users\username\Documents\.....), similarly the installer must also create keys in the registry. During execution, the installed applications must NOT require administrative privileges and must be able to read and write the files in the user folders and read and modify the registry keys and values.
At the moment, however, on the target PC the only way to correctly install the application is to launch it as an administrator and this creates a series of problems. First of all the 'user' files end up in the C:\Users\Administrator\... folder which is not 'readable' by other users, similarly the registry keys are either not readable (if they are set as HKEY_CURRENT_USER or are not editable if they are set as HKEY_LOCAL_MACHINE).
What I was wondering is if it is possible to run the installer with administrative privileges (so without impersonalizing the Administrator user) and if in this way the user folder and the registry root (HKEY_CURRENT_USER) are interpreted correctly by the installer.

[wiebe@CARYA]

If it's not obvious how to do this in LV's installer, I'd assume it's not possible with the LV installer...

---

@michele.santucci wrote:

At the moment, however, on the target PC the only way to correctly install the application is to launch it as an administrator and this creates a series of problems.

---

Do you mean A) user Foo right clicks and selects "run as administrator" or B) user Foo logs out and logs in as administrator? If you tried B) I'd try A). If you tried A) it seems to be an oversight, and I doubt it can be done.

You could of course configure stuff at the first run of the application (bleh) or run a LV exe at the end of the installation (also bleh)...

I think I stick to my answer: InnoSetup might do the trick. InnoSetup is not always easy either but a lot more is possible.

[michele.santucci]

We did not logged in as Administrator for sure.. unluckly I don't remember (I wasn't running the setup by myself) If the setup has been "Run as.." or if the setup have been launched as the logged in user and then the setup itself requested an elevated prompt.

Do you think the first option is equivalent to log in?

I'm not using Innosetup recently... I tought to use WiX.

[rolfk · Accepted solution]

It depends on a lot of things actually that are partly completely out of the installers direct control.

You can have several different users and which one you have depends entirely on the choices your (domain) adminstrator makes.

- local user with admin rights

- a domain user with local admin rights

- a domain user with only normal rights

- a domain administrator with or without local admin rights

Even if your user account has local admin rights, Windows requires an elevation of the current process if it has to modify any important system resources such as installing drivers or modifying protected registry locations.

So if your administrator gave your user account local admin rights, you will not need to login as administrator to install a software but Windows will generally still require you do affirmatively acknowledge an elevation dialog. This is NOT a login, but more of a warning: Yes I know you are logged in as local Administrator but do you really want to allow this process to make security sensitive changes to the system??

If you do not have local admin rights for your current user account, you always will need to reauthenticate with an account with administrative privileges in order to be elevated too. And the process will then for the remainder impersonate this admin account. So access to the registry will redirect CURRENT_USER to whatever is the home registry hive for that admin user. Same for user directories which will now be for the admin account you (re)authenticated with.

You seem to want to set user specific settings in the registry and user directory locations during installation, which is generally not a great idea. A better approach would be to make those changes to locally global locations such as LOCAL_MACHINE or the Common user directory for your application sub directory. Then the application tries to read the CURRENT_USER setting and if it can't find it it will read the LOCAL_MACHINE setting instead and then write a copy with whatever the user wanted to change to CURRENT_USER.

If settings need to be user specific, they should be stored by the application in a user specific location, but your installer should actually not care for which user the application is installed. The installer should if at all, create machine local files and settings that are at least initially independent of the user that will use the application, so they would belong in All Users or a similar location.

[michele.santucci]

It seems that we have a company security rule that restrict user rights on local machine so no domain user can be elected to local Administrator, the only way is to 'impersonate' the Administrator.

The application has a portion of its setting/data files on system folders and a portion into user specifc folders.

And it need to work this way: it's a requirement.

Of course it will need only read access on system resources but read/write on user resources.

As you have suggested I'm moving part of the user setting related management originally made by the installer into the application code (being executed only on the first run) hopefully this will fix some of these issues.