Page 1 of 1
Running a tool as an administrator (reposted from HOWTO)
Posted: Tue Jul 20, 2021 6:26 am
by Nick
I'm trying to use one of the tool options to start the server control panel on my Win10 system, but gives the message:
Requested operation requires elevation
Is there a way to run it as Administrator from the toolbar by setting a parameter or something?
Administrator option on tool
Posted: Tue Jul 27, 2021 10:20 am
by Cloink
Wouldn't you just use the native Windows parameters, is it:
/runas:Administrator
or something like that? after the path/to/exe? You just include this as a parameter within the Tool configuration parameters, if I've got that right...
Posted: Tue Jul 27, 2021 10:44 am
by Nick
Thanks - trying that.
Adding that in the parameters section of tool setup has no effect and adding it directly after the path to the exe makes it unable to find the file.

Posted: Mon Aug 02, 2021 11:56 am
by Cloink
I got that wrong.
"runas" is itself an executable, so your tool needs to run "runas" from the system directory, passing the username and 'real' executable as per usage below. I'm trying on my work machine, I think some security setup is preventing me using it, but I certainly get to the point where I am asked for a password.
From a command prompt:
Code: Select all
C:>runas /?
RUNAS USAGE:
RUNAS [ [/noprofile | /profile] [/env] [/savecred | /netonly] ]
/user:<UserName> program
RUNAS [ [/noprofile | /profile] [/env] [/savecred] ]
/smartcard [/user:<UserName>] program
RUNAS /trustlevel:<TrustLevel> program
/noprofile specifies that the user's profile should not be loaded.
This causes the application to load more quickly, but
can cause some applications to malfunction.
/profile specifies that the user's profile should be loaded.
This is the default.
/env to use current environment instead of user's.
/netonly use if the credentials specified are for remote
access only.
/savecred to use credentials previously saved by the user.
/smartcard use if the credentials are to be supplied from a
smartcard.
/user <UserName> should be in form USER@DOMAIN or DOMAINUSER
/showtrustlevels displays the trust levels that can be used as arguments
to /trustlevel.
/trustlevel <Level> should be one of levels enumerated
in /showtrustlevels.
program command line for EXE. See below for examples
Examples:
> runas /noprofile /user:mymachineadministrator cmd
> runas /profile /env /user:mydomainadmin "mmc %windir%system32dsa.msc"
> runas /env /user:user@domain.microsoft.com "notepad "my file.txt""
NOTE: Enter user's password only when prompted.
NOTE: /profile is not compatible with /netonly.
NOTE: /savecred is not compatible with /smartcard.
And my test output (when run from the command line rather than a TP tool):-
Code: Select all
H:\knkknaks>runas /user:XXX runas_test.bat
Enter the password for XXX:
Posted: Mon Aug 02, 2021 1:54 pm
by Nick
Thanks for trying! I don't seem to be able to make this work - it's not critical - I've put a link on my Windows taskbar instead.
Posted: Mon Aug 02, 2021 4:01 pm
by Cloink
Ha!
I know you said it's not critical, but I got it to work - and from a TP tool.
I noticed that it, runas, was using a user attached to my machine: <machine_name>\<username>.
Looking at the usage more closely: "<UserName> should be in form USER@DOMAIN".
So I added my work domain name to my user, and hunky dory, it works, at least for my runas_test.bat -- when saved to the C: drive only. Note the other user (even if it's your own id again) does not inherit your network mappings.
And of course the other user does not have access to your C:\User\<username> folder, so it needs to be in a common area on the C: drive.
You also have to type in the password each time...
Posted: Mon Aug 02, 2021 4:09 pm
by Nick

*****
Posted: Wed Aug 11, 2021 12:37 pm
by Cloink
...and just on the slim chance anyone else ever happens upon this thread and tries to repeat...
I just wanted to reassure myself that this did indeed work / I could repeat the steps.
Well I recreated the runas_test.bat file on my desktop (forgetting the users folder issue).
Then I remembered the users folder issue and cmd-line "move"d the desktop file to C:temp. It didn't work when I tried to runas /user!
That seemed to carry forward the permissions/ownership from the desktop file, even when moved into C:temp.
So don't do that...