I'm writing some values to HKLM during the installation of my application.
I'm using the PrivilegesRequired=admin flag in my installer, so during the installation, writing to the registry works fine.
However, when I un-install my application, Inno Setup doesn't request admin privileges, so my call to RegDeleteKeyIncludingSubkeys fails.
I would like to ask if it's possible to make it so that Inno Setup requires admin privileges at un-installation as well.
Thank you very much.
Edit: I've read that the uninstaller should contain this information, but for me, it doesn't. I don't even remember how I created the uninstaller...
I found the problem myself:
I forgot to sign the uninstaller.
The Windows Programs & Features uninstaller requires that uninstaller have to be signed.
Once I signed the uninstaller, everything would work as expected.
Related
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
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'm using Inno setup for make a installation to my program.
And I would like to know, how to make the program to be installed in the user desktop by default?
I figured out, I need to use DefaultDirName=.
I need to know, what to write there for install to be on user desktop be default.
Any help?
Use {userdesktop} constant:
[Setup]
DefaultDirName={userdesktop}
You may also consider setting PrivilegesRequired to lowest, as you probably do not need the installer to run with Administrator privileges.
[Setup]
PrivilegesRequired=lowest
I am trying to construct a silent install using Inno Setup. I am using the /SILENT and /VERYSILENT command parameters, and everything works fine, except for the UAC window popping up at the start.
How do I get around this issue?
I have found a few posts loosely mentioning about using SignTool, but other sources have said that this will simply change the UAC box blue with the publisher parameter filled.
Can anyone help here? The scenario is an installer which will be distributed over the internet to update existing software on a machine silently without any user interaction.
To run a setup elevated without the UAC prompt, you need to run it from something that is already elevated. It would defeat the entire point of UAC if programs could elevate without the user controlling access.
Signing the executable does just show the publisher.
The basic idea is to first install a service that runs under the Local System account, and this service will launch your update installers so that updates can bypass UAC, and don't force the end user to run as admin. If you don't want to develop one on your own, there are 3rd party solutions like this:
http://www.autoupdateplus.com/
When your users first install your application, an "updater service" gets installed, and all subsequent updates can be silent.
(We used to use AutoUpdate+, but later decided to roll our own which just downloads the full installer file of our appliation and runs it silently. This wasn't possible with AutoUpdate+, we had to create update packages with the changed files, which turned out to be too much hassle, with too much room for error.)
I have found one solution of it, like If I do the following before Installing my EXE for temporary then on post Installation I revert it. then, I hope my purpose get solved.
[Registry] Root: "HKLM"; Subkey: "SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System"; ValueType: dword; ValueName: "ConsentPromptBehaviorAdmin"; ValueData: "0x00000000"
You can install it as User Software. Then you have no problems with UAC because it is no system wide software. ProgramData must be stored in User Folders and Registery Settings must be done under CurrentUser.
Not sure if you like to do that.
But anyway. You do not have to take care of UAC. Companies will have a deployment server with elevated rights so silent deployment will not force there a UAC message.
The UAC message is the normal behavier
When Inno Setup configured with PrivilegesRequired=admin, it stores uninstall registry key in HKEY_LOCAL_MACHINE.
How can i force to store uninstall registry key in HKEY_CURRENT_USER?
As your title said, you need to use PrivilegesRequired=lowest. Anything other than that, and the "local user" may not be what you expect.
If the setup needs admin permissions to remove the old setup, you can use ShellExec, making sure that the application you're calling as the admin manifest, or you pass the "runas" verb.