My users typically work on locked-down workstations. They lack administrator privileges and cannot install software for themselves. In the past, I've designed my applications to be installed per-machine, not per-user. An administrator installs my application on a workstation, and everyone using that workstation can then use the application.
Now I'm considering switching to a per-user install, but I don't know how that would work in my user environment. Is there a way for an administrator to say "Use my privileges to install this application not for me, but for user X?" Does the administrator have to do one user install at a time, or is there a way to do a batch of installs all at once? In a nutshell, am I making things easier, harder, or impossible for the IT staff? Does any of this depend on my installer? (I'm using Windows Installer.)
Non-administrator users still cannot install unadvertised packages that require elevated privileges. A non-privileged user can install an advertised application that requires elevated privileges if a local system agent advertises the application.
There's no such thing as "install privileges". The only reason that a non-admin user cannot install a conventional application is that the installer typically (a) wants to put the application files in Program Files
which requires admin privilege; and (b) wants to create a registry key in HKEY_LOCAL_MACHINE\Software
and write to it. [Still older installers may also want to write files into system32
, make other global registry changes, and so on, but this is discouraged nowadays.]
A per-user install happens without any administrator privilege. The application files are put in the user's own space, e.g., inside the application data folder, and the application's registry key is created in HKEY_CURRENT_USER\Software
instead of HKLM
. This means the user can install the application themselves without the admin's assistance or permission. [Actually an administrator can lock down the system in such a way that users can't install their own applications, but this isn't common outside of the stricter enterprise environments.]
If an application only supports per-user installation, there is no way for the administrator to install the application on the user's behalf. Each user has to run the installer themselves. [Of course a skilled administrator could automate this so that, for example, the installer runs automatically when the user logs in.]
Whether per-user installation makes things easier or harder on the IT staff depends entirely on the scenario. However, many enterprise sysadmins are unhappy about per-user applications. There are also scenarios (roaming profiles, for example) where per-user applications may either malfunction or cause other problems such as excessive network load or disk quota issues. [And in some enterprises they will be locked out altogether due to software restriction policy, AppLocker, and/or third-party equivalents.]
It is possible for an installer to support both per-machine and per-user installation, so this is usually the best option; alternatively, like Google Chrome, you could provide separate per-user and a per-machine installers for the same application.
If I understand correctly, Windows Installer makes it particularly easy to provide an installer that can do both per-machine and per-user installations. Most .msi files that support per-user installations will also support per-machine installations via the ALLUSERS
property. I'm not sure whether the developer needs to do anything in particular to make this work.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With