Running a tool as an administrator (reposted from HOWTO)

[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?

[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...

[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.

[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:

[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.

[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...

[Nick]

*****

[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...