Run Bat As Admin in PowerShell

Question

I'm running the following from an elevated PowerShell session:

Start-Process .\file.bat -Verb RunAs -Wait

It's opening the bat file, but it's not doing it as administrator. Is there a better way to do this?

Answer 1

• Child processes launched from an elevated process are themselves elevated.

  • Given that you're running from an elevated PowerShell process, as you state, you can simply invoke the batch file directly, in the current console window, which has the following advantages:

    • Execution is (by default and invariably) synchronous.

    • You can capture (or silence) the batch file's output, if any

    • Its exit code is reflected in the automatic $LASTEXITCODE variable:

      # From an already elevated session, invoking a batch file will run 
      # it elevated too.
      .\file.bat
      

  • If you do want to run it in a separate window, you can use your original command (the -Verb RunAs is then implied and may be omitted; no UAC dialog is displayed either way).

• When running from a non-elevated session, your Start-Process -Verb RunAs approach is needed, and the elevated cmd.exe process that runs the batch file of necessity runs in a new window.

  • Caveat re working directory when creating an elevated cmd.exe process (whether directly, with -FilePath cmd.exe, or indirectly with, e.g. -FilePath .\file.bat) or a powershell.exe process (Windows PowerShell):

    • The elevated process' working directory will invariably be C:\Windows\System32, irrespective of the caller's working directory, and irrespective of any -WorkingDirectory argument, which is ignored.

  • Other executables - notably including pwsh.exe, the PowerShell (Core) 7+ CLI - do inherit the caller's working directory.

---

In other words:

• Your approach can be simplified, but it should work.

  • If you unexpectedly aren't permitted to perform an operation in the elevated session, the problem must be unrelated to elevation; notably, files and folders may have ACLs that even administrators aren't allowed to access or modify.

  • Also note the working-directory caveat discussed above.

• A simple way to verify whether a batch file is indeed run in an elevated process is to add the following to it (relying on the fact that net session can only be invoked successfully from an elevated process):

   net session >NUL 2>&1 && echo ELEVATED || echo NON-elevated
  

• Note that whether or not the title bar of the new window starts with Administrator: is not a reliable indicator of whether the session is elevated.

  • Notably, direct invocation of a batch file with Start-Process -Verb RunAs does not cause the title prefix to be appear, even though the resulting cmd.exe process is elevated (use the command above to verify).

  • Only if you call via cmd.exe do you see the prefix, which you can do as follows (but note that it makes no functional difference):

    # Note: The batch file's *full path* must be passed, because 
    #       the elevated process' working dir will be C:\Windows\System32 
    #       if the caller is non-elevated.
    Start-Process -Verb RunAs cmd.exe "/c `"$(Convert-Path .\file.bat)`""
    

Answer 2

You can try something like this:

If (-NOT ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator"))
{   
$arguments = "& '" + $myinvocation.mycommand.definition + "'"
Start-Process "$psHome\powershell.exe" -Verb runAs -ArgumentList $arguments

break
}

Start-Process .\file.bat -Verb RunAs -Wait

If the script runs without administrative privileges the elevation form will be shown. After the user clicked Yes on the popup, your file will be reopened with Admin rights

Answer 3

Okay, I couldn't get anything to run as admin when opening a new window. I didn't realize I could just run it within the same PowerShell session, so I changed it to just running:

.\file.bat

and that is getting me what I need.