I am using the following script to run an executable as an admin:
#include "ifx.h"
export prototype MyFunction(HWND);
///////////////////////////////////////////////////////////////////////////////
//
// Function: MyFunction
//
// Purpose: Calls into Companion to execute the detect camera and all init setup
// code
//
///////////////////////////////////////////////////////////////////////////////
function MyFunction(hMSI)
begin
if REMOVEALLMODE ==0 then //only run if they are installing the product
LAAW_SHELLEXECUTEVERB = "runas";
LaunchApplication (INSTALLDIR ^ "Companion.exe",
"-detect -test -wsdl -exit -nimbus",
"",
SW_NORMAL,
0,
LAAW_OPTION_WAIT_INCL_CHILD | LAAW_OPTION_USE_SHELLEXECUTE);
endif;
end;
On XP, the script above will open up a dialog box asking the user which user the executable should be run as. This allows them to select an admin to run the executable. However, on Windows 7, nothing happens. The installation doesn't ask the user for anything and the installation fails.
Any ideas on why this might be or any other suggestions as to how to run an executable as an admin?
What happens when you launch the application yourself under Win7, I mean outside of InstallShield?
I am thinking it might be due to UAC. A program launched by an installscript doesn not automatically inherit admin privileges from the installshield script.
You can distinguish between XP and all non-XP operating systems like this:
if ( SYSINFO.WINNT.bWinXP ) then
LAAW_SHELLEXECUTEVERB = "open"; // target PC is on Windows XP
else
LAAW_SHELLEXECUTEVERB = "runas"; // Windows 7 (or Vista)
endif;
Here's a Tip from the InstallShield Help Library:
If you are using LAAW_OPTION_USE_SHELLEXECUTE on systems running
Windows Vista or later and you want to launch the application using
the full administrator account (similar to right-clicking the
executable file to be run and clicking Run as Administrator), set
LAAW_SHELLEXECUTEVERB to runas before using LaunchApplication in your
script:
LAAW_SHELLEXECUTEVERB = "runas";
This ensures that the application is always run with full
administrator privileges regardless of whether the application to be
launched has an application manifest with relevant settings. Note that
this may trigger a User Account Control (UAC) prompt for consent or
credentials.
On systems running operating systems earlier than Windows Vista, if
runas is used, a Run As dialog box is displayed. The behavior is
similar to right-clicking the executable file to be run and clicking
Run As. This dialog box enables the end user to select the user
account that should be used to run the application.
Related
I have a program that runs with elevated privileges when I double click on the icon(Task Manger shows Elevated = Yes). I do not want it to run with elevated privileges but I have not been able to figure out how to turn it off.
I checked the following places:
1.)Right Click on the shortcut -> Advanced -> Run as admin is unchecked
2.)Right Click on the shortcut -> Compatibility -> Run as admin is unchecked
3.)Right Click on the exe -> Compatibility -> Run as admin is unchecked
I've tried the following commands:
1.)runas /trustlevel:0x20000 "newapp.exe"
2.)runas /user:domain\username "newapp.exe"
No matter what I do or check the app still runs with elevated privileges. Any ideas on how to resolve this issue is greatly appreciated.
There are at least 4 reasons why Windows might decide to UAC elevate a new process.
requestedExecutionLevel in the manifest is set to requireAdministrator or highestAvailable.
Installer detection.
The compatibility tab for the shortcut or .exe has set certain properties (run as Windows XP etc.)
ShellExecute was invoked with the RunAs verb.
The application manifest is embedded in the .exe or in a file next to it named "applicationname.exe.manifest". You can explore the embedded manifest with a tool like Manifest View or Resource Hacker.
If you did not write the application yourself, do you actually know if it will even work if not elevated? You can try to force it in cmd.exe:
set __COMPAT_LAYER=RunAsInvoker
c:\path\theapp.exe
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 am using the Limited edition and in my installer I have a custom action where I open a cmd.exe and passing a batch file for executing.
The cmd is executing but its not in the elevated permission. I need to execute this in elevated permission since my batch file has operations which needs admin privilege.
I tried many options and the screen shots attached describes what I have done.
Let me know if this is possible with Limited Edition. I am installing in windows 10 machine.
the whole "Elevetad privilege" thing changed a lot during the lasts years.
if I were you, I'd put the schema to version 500 (the last one)
you'll might wan't to double check that your batch file is correctly found, as properties in system context can be unavailable. (use /k so the cmd prompt will not close and you'll be able to see the result of your batch file.)
also if the UAC is disabled on the client machine the user won't have the right to elevate your installer so setting the Require Administrative privilege won't change anything.
in order to be sure, you'll might wan't to use a install condition validating the Privileged property.
I have a windows application with user Interface that do some stuff...
Now my client wants that, when he pushes the power button MyApplication run before he forced to input the username and password!
comment: the system is multi user on windows XP or Seven.
Is it possible anyway?
I found the way to do this was to create a scheduled task with a trigger for "on startup". This starts the application before windows logon. This is particularly useful in a server type environment if you need to have something run that is not a service.
It is simple. The process is.
Run gpedit.msc
Go to computer Configuration -> Windows Setting -> Scripts(Startup/shutdown)
Go to Startup properties then you will get the new windows.
Now add the program that you want to run before login.
The right way to do this is to implement a Windows service.
I've used this article here as I run a Minecraft server which I need to have the console interactive so I can manage the server and running it as a service is not a good solution in such a case: https://www.tenforums.com/tutorials/138685-turn-off-automatically-restart-apps-after-sign-windows-10-a.html
What I did was edit the registry:
Go to HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Create a new DWORD value (if this DWORD doesn't exist already) and
call it RestartApps with the value of 1
This now starts apps that usually startup before you log in and starts the programs in shell:startup
You can not run an exe without first loading the operating system. You can, however, run the exe without logging in first. Just add copy and paste the shortcut for the exe into C:\Documents and Settings\Administrator[or other user name]\Start Menu\Programs\Startup. Then check msconfig to make sure your exe is checked to run on startup.
My product have a ATL/COM based C++ service (32 bit). It get registered and run fine on XP 32 bit and Vista 32 bit.
But now I want to run the same on Windows7 64 bit also. I tried to register the service the following way:
1 I did Copy MyService.exe at C:\Windows\SysWOW64.
2 Then executing "C:\Windows\SysWOW64\MyService.exe" -RegServer from Start->Run
3 Then executing "C:\Windows\SysWOW64\MyService.exe" -Service from Start->Run
But my service is not getting registered. While registering it, I don't get any error message. Also I didn't find any entry in event viewer (I saw event viewer first time. Don't know where to see the log about registration of my service). And I didn't find entry for my service at Control Panel\Administrative Tools\Services.
Please advise me how can I register my service?
Thanks in Advance
Regards
If UAC is enabled on the machine then registering it via Start -> Run is unlikely to work as it would almost certainly need full administrator rights to register its objects and create its service.
Open an Administrator command prompt and try registering it from there.
(Find Command Prompt in the start menu, right-click it and select Run as Administrator.)
Alternatively, instead of using Start -> Run, type the command directly into the Windows 7 start menu and then push Ctrl-Shift-Return to run it as Administrator.
Try commands at cmd running at administrator rights.