2

One of my application has a Windows version, I have made an installer using NSIS and the current version installs into "Program Files".

I understand it only works if the installer is run as an administrator and it might pose problems for some users (enterprise PCs...).

What is the Windows best practice for this kind of installer? Force the user to be admin? Offer the option to install elsewhere?

(I am a UNIX/Mac guy so don't really know the Gospel when it comes to Windows apps)

Here is the NSIS script in case someone want to have a look: https://github.com/nickbnf/glogg/blob/master/glogg.nsi

Nicolas Bonnefon
  • 537
  • 4
  • 12

3 Answers3

1

I recommend you to always set ALLUSERS=1 for those installations.

EDIT

Litte addition so save you endless reading of msdn articles. ALLUSERS=1 forces the install to be per machine. This keeps the user profile clean and makes the software manageable in a corporate environment. You can always install and remove software even if the user is not logged on. Also ALLUSERS=2 (allow per user install) is kinda impossible to remove in such environments.

You can set the property in the property table or via commandline:

msiexec.exe myPackage.msi ALLUSERS=1
Tsagana Nokhaeva
  • 630
  • 1
  • 6
  • 25
weberik
  • 2,636
  • 1
  • 18
  • 11
1

In Windows it's generally considered good practice to require admin access to install software. Enterprises actually like this feature because it means that certain people won't be able to install software without the company's permission. Software should usually go into the Program Files or Program Files (x86) directory and it requires administrator access intentionally.

There are a few exceptions to this rule, but they're rare. In order to install software per-user safely you need to guarantee that:

1) the installer can function from somewhere other than Program Files (or other machine-wide locations).

2) The software itself doesn't write to machine-wide locations.

3) You don't write anything to the machine wide registry locations (e.g. HKEY_LOCALMACHINE).

Honestly this is a more complex issue. It really depends on what you're doing. If you can get away with click-once installations, then that might be the best bet and you can do that with partial trust which means you don't have to require administrator access and you're mostly guaranteed that the usage will be per-user.

Orion Adrian
  • 19,053
  • 13
  • 51
  • 67
  • 3
    I disagree. Not allowing per-user installations just makes extra work for the IT department (i.e., me!) and doesn't actually improve security: per-user software runs in the user's context, so it can't do anything the user couldn't do some other way. Authors of malicious software won't follow your advice anyway, and there's no point in excluding non-malicious software. – Harry Johnston Oct 27 '11 at 23:03
  • If as a corporate admin you really want to prevent users from running non-approved software, you need to investigate Software Restriction Policy or (for Windows 7) AppLocker. – Harry Johnston Oct 27 '11 at 23:03
  • Compare and contrast http://stackoverflow.com/questions/7919359/is-there-a-way-to-identify-the-windows-command-prompt-regardless-of-file-name-or – Harry Johnston Oct 27 '11 at 23:04
  • corporate policy that anticipates published software to adhere to convention seems ill-considered – stackuser83 Mar 08 '14 at 18:53
1

The default option should always be a per-machine installation, i.e., requiring admin access, but if you are able to offer a per-user installation this is an additional bonus which may make some folk's life easier.

Best practice, where feasible, is to provide two versions: one with an installer and one that just runs without needing to be installed. The latter is known as a portable application.

(And while I've got your attention: on behalf of corporate IT everywhere, please make sure your installer includes a documented and tested silent mode, so that we can install the software automatically.)

Harry Johnston
  • 35,639
  • 6
  • 68
  • 158
  • Interesting, so I should definitively lock non-admin out of the installer. In addition to that, I like the idea of providing a portable version (I believe a simple zip with the .exe and the couple of .dll would be enough, right?). I suppose the portable app shouldn't store its config in %APPDATA% too? – Nicolas Bonnefon Oct 28 '11 at 10:24
  • Typically portable apps store their config in the same directory as the application files, or in a subdirectory. In a traditional application this is a very bad idea, of course, but the point of portable apps is that each user has their own self-contained copy. (Naturally, the version with the installer should still use the user's application data folder.) – Harry Johnston Oct 29 '11 at 02:53