Installing to user but require admin

siegeon
29th September 2011 19:53 UTC

Installing to user but require admin
I have been trying to resolve a maddening issue of installing .net 4 full on a clients machine. After a stupid amount of testing it turns out that my own inexperience is more of a factor than anything else. Since I have taken over a legacy product, and I have had little to know support it has been mostly guess work. With that in mind I have attempted to update a very old .nsis script to work with the updated version of my software. The issue is now clear to me, but I need some help on resolving this.

Dot net 4 requires administrator privileges to install from an .nsis script.
If I change the RequestExecutionLevel to admin (from user), then the $PROFILE variable changes from the current user to the administrator, causing everything to be installed in the wrong place.

I need the software to install to the users directory ie. C:\Users\<actual user>\ProgramName….
I also need to install .net 4 full on the user machine.

I see that there is a multiuser.nsh but I do not quite understand if that applies to what I am trying to do, or how to employ it

There may be other factors at play here so I will post the entire script, with a few fields marked out. I have been banging my head against this script for quite a while now… please, anyone help.

see attached code file

Afrow UK
29th September 2011 20:03 UTC

Please edit your post and include your script as a file attachment. I'm not sure that there is a simple solution to your problem which will work on all versions of Windows. You may have to resort to asking the user to install .NET 4 themselves as a prerequisite.

Stu

LoRd_MuldeR
29th September 2011 20:15 UTC

I need the software to install to the users directory ie. C:\Users\<actual user>\ProgramName….

Why? You can't install properly to "C:\Program Files\..." ???

Anyway:

I also need to install .net 4 full on the user machine.

You can explicitly set "RequestExecutionLevel user" to make sure installer won't get elevated. Then the $PROFILE will point to the profile of the (potentially "restricted") user who has executed the installer. After that, Exec() and ExecWait() may fail to run executables, which require elevation (via Manifest). That probably applies to .NET Installer. But you can use ExeShell() - maybe with "runas" verb - to run the .NET installer from a non-elevated NSIS installer, which should trigger an UAC dialog and, if the user allows, run the 2nd installer elevated ...

siegeon
29th September 2011 20:54 UTC

Why? You can't install properly to "C:\Program Files\..." ???

I have no idea, but management is resistant to the idea, and they insist that all of our products install this way...

Edit.
<Never mind I figured it out, playing with that command now>

Edit. 2

That did the trick, this is the exact result I was looking for, thank you very much for for hte help!

LoRd_MuldeR
29th September 2011 21:33 UTC

Originally posted by siegeon
I have no idea, but management is resistant to the idea, and they insist that all of our products install this way...

You should explain them, that this undermines the security concept of modern operating systems: Install program files to locations where "normal" users/applications don't have access, so malware or gawky users cannot mess with those files. Not a very good advertisement.

(If the idea is to completely get away without elevation, this is bound to fails anyway as soon as you have to install .NET)

siegeon
29th September 2011 22:05 UTC

I understand that Mulder, so rather then installing to

!define INSTALL_BASE "$PROFILE\${PRODUCT_PUBLISHER_FOLDER}"

what command would I use instead?

Also I am confused on one point, if the user who is logged in is installing the software is "restricted" why would installing to program files make a difference? And since this software requires and one point or another administrator privileges, then theoretically should the whole thing require administrator rights to install? I know we sell this product to people on various levels of managed systems, where a base user needs to be able to install our software on their system. The blow back from that is that we also require this .net 4 full... Im not sure what the best approach here is.

LoRd_MuldeR
29th September 2011 22:33 UTC

Originally posted by siegeon
I understand that Mulder, so rather then installing to

!define INSTALL_BASE "$PROFILE\${PRODUCT_PUBLISHER_FOLDER}"

what command would I use instead?

!define INSTALL_BASE "$PROGRAMFILES32\${YOUR_COMPANY_NAME}\${YOUR_PRODUCT_NAME}"

Originally posted by siegeon
Also I am confused on one point, if the user who is logged in is installing the software is "restricted" why would installing to program files make a difference? And since this software requires and one point or another administrator privileges, then theoretically should the whole thing require administrator rights to install?

On Vista and later, UAC will run every application (including installers*) with restricted rights - even when the user is an Admin with full rights. Elevation can give applications the full rights. For "Admin" users UAC elevation will only need a click on Yes and the app will still run under the current user's account. For "Restricted" (non-admin) users UAC elevation will ask the user the enter the login credentials of an Admin account and the app will then run under that account. In the latter case the meaning of the user-specific $PROFILE** (and everything that lies in that folder) will change, because the application is running under a different user. At the same time $PROGRAMFILES[32/64] is not user-specific. It's a system-wide folder that will be identical, no matter what account the application is running under...

(*) It has to be noted that Windows will automatically detect and try to elevate NSIS-based installers, if you don't use "RequestExecutionLevel" at all

(**) At least as long as ShellVarContext is set to "current" and not to "all"

I know we sell this product to people on various levels of managed systems, where a base user needs to be able to install our software on their system. The blow back from that is that we also require this .net 4 full... Im not sure what the best approach here is.

Well, installing software generally requires Admin rights. That's because most installers will require elevation. And that is because most installers will correctly install program files to the protected "C:\Program Files" folder and/or will need to install (or modify) system files. A user who wants to install software on the computer must be either logged in with an "Admin" account or must have access to Admin login credentials at least. If somebody doesn't have access to an Admin account, then that's probably for a reason and that person shouldn't be trying to install the software to the computer (but ask the company's administrator team instead). Last but not least: Your installer will ultimately require Admin rights - regardless of where you install the program files to - anyway. That's because you need to install the .NET Framework. So then, why not install your program files correctly to $PROGRAMFILES right away ???

siegeon
29th September 2011 22:57 UTC

Mulder thank you again, that was an excellent explanation, I now understand, ad can approach management in the next meeting about this.

Siegeon.

MSG
30th September 2011 05:34 UTC

Note that installing to Program Files is not a goal in itself. It is however the proper thing to do, if you're installing for ALL USERS. And because admin-only installers should always install for all users, this also means that installing to Program Files is the proper thing to do if you have an admin-only installer.

Regardless, many user-level users on older Windows versions are user-level because they choose to be. They don't want to run installers at admin level for security reasons. Personally, I would definitely prefer to install .NET myself at admin level (because I trust microsoft's installers), and then install your app at user level. I admit however that this scenario applies only to an increasingly small number of people, now that UAC exists.

siegeon
3rd October 2011 16:48 UTC

Due to the way this software was created it is a single user product, and our license covers that single user, should other users want to use our software they are obligated to purchase their own. Granted this is something that should be resolved within the software though a login system, but as there is never enough time its something far down on the list. That being said the reason we are installing to the individual user profile is to prevent access to other users. As we are targeting users it does put us in a bit of a quandary, we require Dot Net 4 full, and granted the installation of Dot Net is an administrators task on a managed system, but the solution reached in this discussion is the closest to a perfect solution I can get.