21

Is it possible to switch from normal mode to administrator mode in command line? I don't want to open command line by right clicking and selecting "run as administrator". Thanks

culter
  • 507
  • 2
  • 9
  • 16

7 Answers7

21

Or from within Powershell:

Start-Process powershell -Verb runas
Chad Miller
  • 1,101
  • 8
  • 11
  • My powershell(on Win7) doesn't have the runas verb... should it? I checked with 'verb | findstr /B /C:"R"'. Runas isn't on the list. – Totem Jan 26 '15 at 12:33
  • For me, this is the most valuable answer, but I have to choose the "No" answer as the right one, because there is no possibility to switch the user modes. Thank you, Chad. – culter Jan 17 '18 at 15:05
  • How do you start the new powershell in the same path as the one into which you type this command? It opens in a default path instead of in the path where I was. – Gabriel Staples Aug 04 '21 at 15:14
11

The answer is no. The "full administrative token" is associated with an .EXE when it's launched. You need to start a new CMD.EXE to get full-admin privs. To make UAC a bit more bearable, you can enable "auto-admin approval" through group policy.

Simon Catlin
  • 5,232
  • 3
  • 17
  • 20
  • 1
    To make UAC more bearable you'd have to disable it entirely. – Ansgar Wiechers Sep 14 '12 at 20:06
  • 4
    @AnsgarWiechers: I hope this comment was not serious. It seems a bit lame to encourage anyone to disable UAC completely. – Sk8erPeter Dec 31 '13 at 10:15
  • 3
    @Sk8erPeter I am quite serious about this. If you're aiming for a secure system: disable UAC and use separate accounts (an admin account for administrative tasks and an account without administrative privileges for day-to-day work). UAC is just a lame workaround that Microsoft invented so that their customers can remain members of the administrators group all the time without actually having admin privileges all the time. – Ansgar Wiechers Jan 03 '14 at 10:26
  • @AnsgarWiechers: it's funny that you call UAC a "lame workaround" when it solves the problem of users logged in all the time with a user that is a member of the administrators group. If you did it on XP, all the programs could run with elevated privileges (so they could harm your system too). Now if you DO NOT disable UAC (which is recommended) it's only possible if you explicitly give them these privileges in the UAC popup (if being logged in as part of the admin group, you just don't have to type in the password all the time). Calling it lame is like calling Linux's `sudo` a lame workaround. – Sk8erPeter Jan 04 '14 at 11:42
  • 1
    @Sk8erPeter As I already said: the solution to the problem is using separate accounts for administrative and non-administrative tasks (a solution that has been working since Windows 2000 at least, and on Unix even longer than that). UAC is just a lame way of working around the issue and making everything more complicated in the process. And `sudo` is something entirely different from UAC as it allows to selectively grant privileged execution of particular commands on particular hosts to particular groups/users. – Ansgar Wiechers Jan 04 '14 at 12:03
  • @AnsgarWiechers: I've already read what you already said :) (repeating yourself (like that it's lame) is not a good argument). Yes, `sudo` is different, you don't say?! :)) (I only mentioned that because e.g. in terminal you have to type `sudo` to act as root. Not the best comparison, I admit that. `sudo` could rather be compared to `runas` command (the latter is a bit more limited).) I think you didn't understand the main point: **the average user *WILL NOT* create separate accounts for administrative and non-administrative tasks. Why would it be lame to count on it?** – Sk8erPeter Jan 04 '14 at 12:51
  • 1
    @Sk8erPeter *\*sigh\** The average user is already being forced to create separate accounts during the installation process (and has been for more than a decade). Only that Microsoft chose to make that additional user a member of the Administrators group as well rather than doing The Right Thing(tm). Anyway, I don't think SF is the right place for this kind of discussion, so I'll excuse myself from it. – Ansgar Wiechers Jan 04 '14 at 13:23
  • 1
    @AnsgarWiechers: I agree, this is not the right place to discuss it. I think a right closure of this debate can be that **disabling UAC** entirely **is** a **very lame** thing to do. ;) – Sk8erPeter Jan 04 '14 at 13:36
  • @Sk8erPeter No. – Ansgar Wiechers Jan 05 '14 at 12:59
  • @AnsgarWiechers: _*sigh*_ (`yes`) like in kindergarten ;) Let's stop it now. Ciao! – Sk8erPeter Jan 05 '14 at 21:39
1

I managed to do it as follows. I put the following line on top, which will restart the script with administrator rights (in a separate window) via PowerShell, if the cmd had not already been started as administrator. Aesthetically it's not perfect, but it does the job.

net.exe session 1>NUL 2>NUL || (powershell "Start-Process -FilePath Cmd.exe -ArgumentList \"/c %~dpnx0\" -Verb RunAs" & goto :eof)
Ronny D'Hoore
  • 131
  • 3
1

How about this:

runas /user:administrator cmd.exe
quanta
  • 51,413
  • 19
  • 159
  • 217
  • 1
    To my understanding, this requires the *actual* Administrator account to be active (`Enter the password for administrator:`). It is not identical with simply running the command prompt with elevated privileges. – Oliver Salzburg Sep 14 '12 at 14:33
1

You can't really "switch" between the two modes, but there are some 3rd party tools that let you launch programs from the command line in the elevated admin. Provided you drop them into a working path, you could, for example, use "elevate cmd" from the start menu or from an existing command prompt to start a new session in the elevated mode.

Rex
  • 7,895
  • 3
  • 29
  • 45
1

You can have a shortcut to cmd.exe and just modify the Advanced properties tab to "Run as Administrator".

TheCleaner
  • 32,627
  • 26
  • 132
  • 191
1

if you are in visual studio code, in configuration you can add this:

    "terminal.integrated.shellArgs.windows": [
        "-Verb runas"
    ],
madwyatt
  • 166
  • 3