I was arguing with my colleague about this topic.
There are two main question:
Can user (not admin) install a desktop app for all users in windows (7, 8.1, 10)?
Can user update this app without admin rights?
As I know, windows will request for admin rights if we are installing some desktop app for all users.
If a user doesn't have admin rights, he won't able to modify files which admin created. So, a simple user aren't able to update an app that was installed for all users.
Am I wrong?
If we want to install an app that will be for all users, do we exactly need admin rights?
You cannot install apps for all users without certain write privileges since you generally need to modify %ProgramFiles%, the "common" start menu and HKEY_LOCAL_MACHINE to install an app. A normal user cannot write to these locations. A member of the now deprecated power-users group can install most applications for all users even though they are not a full administrator unless the installer specifically checks for administrator rights.
A non-admin user can however install patches to an app installed for all users if the .MSI is signed, this is called User Account Control (UAC) Patching.
Chrome and Firefox use an alternative approach with a Windows service and scheduled tasks. This also requires an administrator to perform the initial installation.
Related
My installer run in all users, and it saves user information in the AppData folder.
The problem is that, when the installation is finished, an executable is launched by means of an Exec and it is launched as the administrator user, so all the session data is stored in the administrator's AppData. I want to run the installation as Admin but the last step as the current user.
RequestExecutionLevel admin
Can I launch my application as the current user? Can I keep the current user before ask for admin privilages?
The Microsoft guidelines say:
Certification requirements for Windows Desktop Apps
Apps must install to the correct folders by default
10.6 Your app must write user data at first run and not during the installation in per-machine installations. When the app is installed, there is no correct user location in which to store data.
If you have some sort of default user data/template you should install that in %ProgramFiles% or %ProgramData% and your application should copy that data to %AppData% the first time a user runs your application.
The ShellExecAsUser and StdUtils plug-ins can be used to execute your application as the "real" user on the finish page.
The UAC plug-in allows you to access the "real" users %AppData% and registry but I don't recommend this approach because the plug-in is hard to use and it really promotes incorrect behavior. You are very likely to end up with a install pattern that only works for the initial user and not other users on the same machine.
We are writing an installer for our Windows tool. As our tool uses an updater (wyUpdate) and we want that users WITHOUT Administator rights can performs updates. Which is the right directory to install the app to? The standard C:\Program Files requires Administrator rights, so we have discarded this option. After reading a bit on the Web, we have chosen AppData, i.e. C:\Users\USERNAME\AppData\Local.
Is this best practice? Or should we use another directory?
If you do not want to allow your users to mess with the installed program, you have to install it to a folder that needs Administrator privileges.
To allow an automatic update of such application, you need to develop/install a service that runs with Administrator privileges, which will update the installation. This is what Windows Update, Mozilla Maintenance Service, Google Chrome Elevation Service, Adobe Acrobat Update Service and similar services do.
If you do not want to implement a service, but you want the application to be used by all users of the machine, you need to install it to a folder that can be accessed by all users, yet does not need Administrator privileges. You can for example use C:\Users\Public. See also Is there a shared folder in Windows to which non-elevated users have write access?. You can use PUBLIC environment variable to resolve that path.
If the application is to be used by one user only, then you are ok with using C:\Users\Username\AppData\Local – {userappdata} in Inno Setup.
Related question: Deploying application with .NET framework without admin privileges
A very common question about creating (Inno Setup) installers revolves around accessing/modifying a profile of a specific user (the currently logged in user) from an installer that runs with elevated/Administrator privileges.
Doing this has many drawbacks and is error prone.
All the existing answers cover part of the problem (registry, files, desktop icon, etc). A purpose of this question is to collect answers that address the problem globally, with all possible approaches.
Inno Setup does not have any built-in mechanism to access or modify user environment from installer running with elevated/Administrator privileges.
All the attempts to achieve this rely on tricks like:
runasoriginaluser flag or ExecAsOriginalUser function. Some examples:
Modifying or accessing registry of logged in user:
Inno Setup Creating registry key for logged in user (not admin user) or
How to read registry HKCU for logged In user from Inno Setup installer running as administrator
Accessing AppData folder of logged in user:
Inno Setup always installs into admin's AppData directory or
Inno Setup Using {localappdata} for logged in user or
Inno Setup - puts user files in admin documents.
or using {user*} constants.
Though these are not reliable, at least for these reasons:
When the current user does not have Administrator privileges, (s)he needs to enter Administrator credentials on installer UAC prompt. That switches the installer to a different user. So {user*} constants will not refer to the user that initiated the installation.
When the user explicitly runs the installer with elevated privileges, e.g. by right-clicking the installer and selecting "Run as administrator" or running it from another elevated application (file manager), the "original user" for runasoriginaluser flag or ExecAsOriginalUser function will already be elevated.
In corporate environments, applications are installed by Administrator, who is not the user that will be using the application.
The only correct generic solution to this problem is to defer a setup of the user environment only to the actual user session.
Easiest is to have the application itself do the setup on its first run.
The installer can only deploy shared files that the application can use for the setup.
If you cannot modify the application for whatever reason, you would have to iterate all accounts and modify them:
for files: Inno Setup Create individual shortcuts on all desktops of all users
for registry: Uninstall auto-run registry entries for all users
If you need to make sure the settings get distributed to accounts that get created only after installation, see How to install files for each user, including future new users, in Inno Setup?
If you are happy with a fact that the application will be setup for the logged in user only, use PrivilegesRequired=lowest:
[Setup]
PrivilegesRequired=lowest
Then the {user*} constants will correctly refer to the current user's folder.
If you still need Administrator privileges for some sub-task of the installation, you can requests privileges elevation for the sub-task only:
Inno Setup - Register components as an administrator
Inno Setup - Access unprivileged account folders from installer that requires privileges
If you want to prevent user from breaking this by explicitly running the installer with Administrator privileges, see
Can't get Inno Setup postinstall Run item to runasoriginaluser or
my answer to How to write to the user's My Documents directory with installer when the user used 'Run As Administrator'.
Or you can programmatically find out, what is the account of the current Windows logon session:
Determine if Administrator account that runs elevated Inno Setup installer is the same as the account of the current Windows logon session.
Another option is to allow the installer to install for the current user only:
Make Inno Setup installer request privileges elevation only when needed
I have a Delphi 6 program that for most users installs fine while running under a user account without admin privileges. However, on some systems it triggers a request for admin rights. Unfortunately mine isn't one of them so it's hard for me to diagnose this problem. I use InnoSetup 5.1.9 to build my install programs.
How can I figure out what I need to change about my installation program's configuration to neutralize the need for admin rights on some people's systems? It's causing trouble for my system because during installation, certain program data files are being copied into the admin account's application data folder. Then when my program is launched under a user account, those files can not be found since they are not in the user account application folder, where they are expected to be.
This happens due to default PrivilegesRequired directive value, which is, by default configured to require administrator elevation. If you don't need this, simply change in your InnoSetup script, value of this directive explicitly to something like this:
[Script]
PrivilegesRequired=lowest
From the reference:
When PrivilegesRequired is set to lowest, Setup will not request to be
run administrative privileges even if it was started by a member of
the Administrators group. Additionally, the uninstall info root key
will always be HKEY_CURRENT_USER, and the "common" forms of the Shell
Folder constants are mapped to the "user" forms, even if
administrative privileges are available.
I have written a WPF application.
When it is installed on client machines, they are prompted for a username and password so that they have administrator privileges to use the application.
I need administrator privileges because my application opens ports and writes files to the file system.
Is it possible to allow any user to run the application without being prompted for an administrator username and password and to elevate the application to run with administrator privleges?
Thanks
When your app is installed, it will prompt for admin rights if the installation program has been marked for admin execution. This is normally only required if you want to install to a location available to multiple users, such as within the Program Files folder hierarchy. An MSI will raise a UAC prompt by default, but it's easy to make an MSI with WIX that doesn't raise a UAC prompt.
When your app is run (by a user without admin rights), it will ask for admin rights if the app itself has been marked for admin execution. This is partly under your control, but can overridden by users on the client machine.
An app that writes to file system folders doesn't require admin rights as long as the user running the app has permission to those folders. Generally you can make this work by writing to a location that's accessible to each user.
However, I believe that opening a port does need admin rights if the app is doing anything more than querying statistical information.
If your app does need admin rights to run, and you don't want your non-admin users to see a UAC prompt during program execution, then I suggest you divide your app into 2 parts.
The first part is a Windows service that runs under a privileged user such as LocalSystem and is configured to interact with desktop programs. This service does all of the admin-related tasks, and will need to be setup by an installer that requests admin rights.
The second part is the WPF program that doesn't do anything privileged. If you mark this WPF program as not needing elevation, your end-users will never see a UAC prompt when running it, because all the privileged work is being done by a service that's always running.