Running a command as Administrator using PowerShell?

Question

You know how if you're the administrative user of a system and you can just right click say, a batch script and run it as Administrator without entering the administrator password?

I'm wondering how to do this with a PowerShell script. I do not want to have to enter my password; I just want to mimic the right-click Run As Administrator method.

Everything I read so far requires you to supply the administrator password.

Levis

Try gsudo. A free open-source sudo for windows that allows to execute as admin from the command line. A UAC pop-up will appear. – Drabble

2024: the new sudo for Windows should help. – Flanders

Answer 1

If the current console is not elevated and the operation you're trying to do requires elevated privileges then you can start powershell with the Run as Administrator option :

PS> Start-Process powershell -Verb runAs

Microsoft Docs: Start-Process

Endo

From within a CMD window, the shortest version of this is: powershell start cmd -v runas. To verify the newly acquired privileges, run: net sess. – Insuperable

Remark: The short version should only be used by typing. Inside a script you should use the full length for readability reasons. – Pikestaff

Start-Process wt -Verb runAs for starting windows terminal as admin – Manzo

The question is how to run a command, not to start elevated PowerShell console. – Andradite

@ﾤﾡ No, it is how to start an elevated PowerShell console. See this line in OP's question: "I just want to mimic the right-click Run As Administrator method" – Wolffish

@Wolffish "Run as Administrator" doesn't assume a separate console and doesn't need it. All it needs is an elevation token. Letting alone your unneeded interpretation when the question clearly says "run a command". One doesn't need a console to run a command at all. – Andradite

@ﾤﾡ The body of the post clearly states, multiple times, that this question is about right-clicking a file and 'running as administrator'. It's great to achieve the same outcome via a different avenue if you know how, but please don't mislead others by suggesting the question is not asking what it is asking. – Wolffish

@Wolffish No, it isn't. "Right-clicking" is only used as an illustration that creates the same outcome. Illustrations like these are used to educate children. Now please don't bug me with your useless commentary and better learn the meaning of the relevant words: "run", "console", "elevation token", "command processor". – Andradite

@ﾤﾡ OK, feel free to continue ignoring the contents of questions, and the rest of us will just continue ignoring you. – Wolffish

@Wolffish Excuse me, the rest of who? Are you speaking on behalf of a group of users? What is your mandate? Or is it just your fantasy about representing someone? Not that I care about however large group of people ignoring me in case they are incapable of telling the syntax and the semantics apart. – Andradite

Start-Process wt -Verb runAs -ArgumentList "cmd needs super user role" is closer to sudo .... – Redvers

Answer 2

Here is an addition to Shay Levi's suggestion (just add these lines at the beginning of a script):

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

This results in the current script being passed to a new powershell process in Administrator mode (if current User has access to Administrator mode and the script is not launched as Administrator).

Kinard

Easily modified to just throw an error when not run as admin. Just take the if statement and put a throw inside the then block. – Approve

The only syntax that worked for me is in the original post, not the one by G.Lombard nor anjdreas – Krever

Is there a way of supressing windows If you want to run powershell as administrator? For applications in which you need to run this silently having your user asked can be bothering. – Stenotypy

This answer doesn't preserve the working-directory. See here for one which does: https://mcmap.net/q/22621/-running-a-command-as-administrator-using-powershell – Guardado

This fails when it is inside of a function definition. Must be outside, otherwise it opens a new admin window and immediately closes. – Fireweed

Doesn't work if script launched from mapped network drive as admin doesn't have same mapped drive. To fix you'd have to run from UNC address or have code that expands network driver to UNC then relaunch from UNC – Wilser

@Wilser unless, of course, you manually map the network drive in an elevated console first. – Superannuate

Answer 3

Self elevating PowerShell script

Windows 8.1 / PowerShell 4.0 +

if (!([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")) { Start-Process powershell.exe "-NoProfile -ExecutionPolicy Bypass -File `"$PSCommandPath`"" -Verb RunAs; exit }

# Your script here

Irritation

Yikes. So, here is a much better way: if([bool]([Security.Principal.WindowsIdentity]::GetCurrent()).Groups -notcontains "S-1-5-32-544" { Start Powershell -ArgumentList "& '$MyInvocation.MyCommand.Path'" -Verb runas } – Grateful

Drawback: If you enter a non-admin in the prompt, you end in an endless fork-exit loop. – Murrell

but this don't pass args – Faitour

To pass args, I modified it to: if (!([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")) { Start-Process powershell.exe "-NoProfile -ExecutionPolicy Bypass -File `"$PSCommandPath`" `"$args`"" -Verb RunAs; exit } – Mcinnis

You can add Write-Host "`n`nPress any key to exit scrpt ..."; $host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown") > $null; at the end of your script so that the newly opened admin shell doesn't close automatically. – Diplomatist

This answer doesn't preserve the working-directory. See here for one which does: https://mcmap.net/q/22621/-running-a-command-as-administrator-using-powershell – Guardado

This answer probably only works on English-language systems. – Somehow

@Irritation can confirm if still works on Powershell 5.1? – Dreher

For me this worked just fine. I just changed powershell.exe to pwsh.exe and using it with PS1 script that I just right click and select Run with PowerShell 7. – Caseose

How do you preserve the arguments you pass in though? I tried @Mcinnis 's fix but it seems adding $args doesn't work. It just closes the newly opened PS session and then exits the script. – Adenitis

@Adenitis this works for me, also restarts in 64 bit if it was started in a 32 bit process on a 64 bit OS $CommandLine = "-NoProfile -File '$( $MyInvocation.MyCommand.Path )' $( $MyInvocation.UnboundArguments )" Start-Process -FilePath "$( $pshome -replace "syswow64", "System32" )\powershell.exe" -Verb Runas -ArgumentList $CommandLine – Fireweed

Note that it won't work if run from a drive other than C: – Slung

Also, the current working directory is different after elevation. Return to it after w/ this: $path = Split-Path -Path $MyInvocation.MyCommand.Path; cd $path – Slung

Answer 4

Benjamin Armstrong posted an excellent article about self-elevating PowerShell scripts. There a few minor issue with his code; a modified version based on fixes suggested in the comment is below.

Basically it gets the identity associated with the current process, checks whether it is an administrator, and if it isn't, creates a new PowerShell process with administrator privileges and terminates the old process.

# Get the ID and security principal of the current user account
$myWindowsID = [System.Security.Principal.WindowsIdentity]::GetCurrent();
$myWindowsPrincipal = New-Object System.Security.Principal.WindowsPrincipal($myWindowsID);

# Get the security principal for the administrator role
$adminRole = [System.Security.Principal.WindowsBuiltInRole]::Administrator;

# Check to see if we are currently running as an administrator
if ($myWindowsPrincipal.IsInRole($adminRole))
{
    # We are running as an administrator, so change the title and background colour to indicate this
    $Host.UI.RawUI.WindowTitle = $myInvocation.MyCommand.Definition + "(Elevated)";
    $Host.UI.RawUI.BackgroundColor = "DarkBlue";
    Clear-Host;
}
else {
    # We are not running as an administrator, so relaunch as administrator

    # Create a new process object that starts PowerShell
    $newProcess = New-Object System.Diagnostics.ProcessStartInfo "PowerShell";

    # Specify the current script path and name as a parameter with added scope and support for scripts with spaces in it's path
    $newProcess.Arguments = "& '" + $script:MyInvocation.MyCommand.Path + "'"

    # Indicate that the process should be elevated
    $newProcess.Verb = "runas";

    # Start the new process
    [System.Diagnostics.Process]::Start($newProcess);

    # Exit from the current, unelevated, process
    Exit;
}

# Run your code that needs to be elevated here...

Write-Host -NoNewLine "Press any key to continue...";
$null = $Host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown");

Foundation

I was not getting the script name and params properly resolved, so I wrapped the execution in cmd.exe /c $newProcess = new-object System.Diagnostics.ProcessStartInfo “cmd.exe” $newProcess.Arguments = ‘/c ‘ + [System.Environment]::GetCommandLineArgs() $newProcess.WorkingDirectory = [environment]::CurrentDirectory – Arbor

Is there any advantage to doing it like this instead of Start-Process? I am curious about the differences, between this method and the others posted above and on other threads. They both rely on .NET, but this method more heavily... – Belfort

I found various comments associated with the direct link to Armstrong's post (initial sentence of this post) to be very helpful as well. – Ullman

This answer doesn't preserve the working-directory. See here for one which does: https://mcmap.net/q/22621/-running-a-command-as-administrator-using-powershell – Guardado

Answer 5

Here's a self-elevating snippet for Powershell scripts which preserves the working directory:

if (!([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) {
    Start-Process PowerShell -Verb RunAs "-NoProfile -ExecutionPolicy Bypass -Command `"cd '$pwd'; & '$PSCommandPath';`"";
    exit;
}

# Your script here

Preserving the working directory is important for scripts that perform path-relative operations. Almost all of the other answers do not preserve this path, which can cause unexpected errors in the rest of the script.

If you'd rather not use a self-elevating script/snippet, and instead just want an easy way to launch a script as adminstrator (eg. from the Explorer context-menu), see my other answer here: https://mcmap.net/q/22623/-how-to-start-powershell-script-from-bat-file-with-proper-working-directory

Guardado

Answer 6

You can create a batch file (*.bat) that runs your powershell script with administrative privileges when double-clicked. In this way, you do not need to change anything in your powershell script.To do this, create a batch file with the same name and location of your powershell script and then put the following content in it:

@echo off

set scriptFileName=%~n0
set scriptFolderPath=%~dp0
set powershellScriptFileName=%scriptFileName%.ps1

powershell -Command "Start-Process powershell \"-ExecutionPolicy Bypass -NoProfile -NoExit -Command `\"cd \`\"%scriptFolderPath%`\"; & \`\".\%powershellScriptFileName%\`\"`\"\" -Verb RunAs"

That's it!

Here is the explanation:

Assuming your powershell script is in the path C:\Temp\ScriptTest.ps1, your batch file must have the path C:\Temp\ScriptTest.bat. When someone execute this batch file, the following steps will occur:

1. The cmd will execute the command

   powershell -Command "Start-Process powershell \"-ExecutionPolicy Bypass -NoProfile -NoExit -Command `\"cd \`\"C:\Temp\`\"; & \`\".\ScriptTest.ps1\`\"`\"\" -Verb RunAs"
   

2. A new powershell session will open and the following command will be executed:

   Start-Process powershell "-ExecutionPolicy Bypass -NoProfile -NoExit -Command `"cd \`"C:\Temp\`"; & \`".\ScriptTest.ps1\`"`"" -Verb RunAs
   

3. Another new powershell session with administrative privileges will open in the system32 folder and the following arguments will be passed to it:

   -ExecutionPolicy Bypass -NoProfile -NoExit -Command "cd \"C:\Temp\"; & \".\ScriptTest.ps1\""
   

4. The following command will be executed with administrative privileges:

   cd "C:\Temp"; & ".\ScriptTest.ps1"
   

   Once the script path and name arguments are double quoted, they can contain space or single quotation mark characters (').

5. The current folder will change from system32 to C:\Temp and the script ScriptTest.ps1 will be executed. Once the parameter -NoExit was passed, the window wont be closed, even if your powershell script throws some exception.

Venusian

If I do this, I get a popup that asks me if I allow PowerShell to make changes to my system. This makes it unusable for automation. – Hashimoto

@JohnSlegers, if you need to automate it, it's your responsibility to make sure the automated process is run as an administrator. If you could automatically elevate a non-admin process to an admin process without user interaction, that would defeat the purpose of requiring a process to have admin privileges in the first place. – Phenyl

@Phenyl : As a release engineer, my job involves creating and maintaining build processes that run fully automatically, either periodically, or when certain criteria are met. Some of these processes need admin privileges, and requiring user input makes a process unusable in this context. — In Linux, you can achieve this by using the sudo command and configuring the user you use for automated process with NOPASSWD: ALL in the sudoers file. – Hashimoto

This is a better answer than the others because it preserves the working directory. I put together some one-line variants of this approach here (one for cmd/batch, one for Explorer context-menu entries, and one for powershell): https://mcmap.net/q/22623/-how-to-start-powershell-script-from-bat-file-with-proper-working-directory – Guardado

FWIW, edit #5 by @mems was wrong for me. The backslash added after %scriptFolderPath% caused an error for me. – Warman

Seems kind of like a kludge using a batch file to run a powershell script when the powershell script has 10x the power and flexibility of a batch file... Just my $.02 – Fireweed

What is the backtick character doing here? Why does this work? I'm happy with the answer but I don't understand why putting those backticks make it work. – Unsling

I reverted edit #5 because I also had the error mentioned by @Warman – Maziar

@Unsling the backticks isolate the double quote characters from the backslash characters so that the double quote characters aren't unescaped prematurely. – Superannuate

Answer 7

Using

#Requires -RunAsAdministrator

has not been stated, yet. It seems to be there only since PowerShell 4.0.

http://technet.microsoft.com/en-us/library/hh847765.aspx

When this switch parameter is added to your requires statement, it specifies that the Windows PowerShell session in which you are running the script must be started with elevated user rights (Run as Administrator).

To me, this seems like a good way to go about this, but I'm not sure of the field experience, yet. PowerShell 3.0 runtimes probably ignore this, or even worse, give an error.

When the script is run as a non-administrator, the following error is given:

The script 'StackOverflow.ps1' cannot be run because it contains a "#requires" statement for running as Administrator. The current Windows PowerShell session is not running as Administrator. Start Windows PowerShell by using the Run as Administrator option, and then try running the script again.

+ CategoryInfo          : PermissionDenied: (StackOverflow.ps1:String) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : ScriptRequiresElevation

Budding

Unfortunately all it does is make the script fail with an error if shell has no admin privileges. It doesn't elevate by itself. – Wagers

PS3 appears to give an error as suggested. I get Parameter RunAsAdministrator requires an argument. @Budding I'm not convinced they always are thinking. – Approve

Answer 8

You can easily add some registry entries to get a "Run as administrator" context menu for .ps1 files:

New-Item -Path "Registry::HKEY_CLASSES_ROOT\Microsoft.PowershellScript.1\Shell\runas\command" `
-Force -Name '' -Value '"c:\windows\system32\windowspowershell\v1.0\powershell.exe" -noexit "%1"'

(updated to a simpler script from @Shay)

Basically at HKCR:\Microsoft.PowershellScript.1\Shell\runas\command set the default value to invoke the script using Powershell.

Rubinrubina

It doesn't work, you're creating a '(default)' key, not updating the '(default)' key value. I was able to condense the code to a one-liner that works for me. Can you test it? New-Item -Path "Registry::HKEY_CLASSES_ROOT\Microsoft.PowershellScript.1\Shell\runas\command" -Force -Name '' -Value '"c:\windows\system32\windowspowershell\v1.0\powershell.exe" -noexit "%1"' – Endo

@Shay Levy - Hi Shay, thanks for updated one. I have updated the answer with it. It does work. But the one I had worked as well, though it was verbose. I hadn't done much reg edit with Powershell, but doing it with "(default)" was something that I had seen as an example. It did not create a new key ( which something like default would have) but did update the default key as expected. Did you try it out or just guessed from the (default) part? – Rubinrubina

I tried it. It created a '(default)' key under the command key. – Endo

This worked for me after some minor changes to the registry value: "c:\windows\system32\windowspowershell\v1.0\powershell.exe" -ExecutionPolicy RemoteSigned -NoExit "& '%1'" – Audrit

The registry value in the answer has all kinds of problems. It doesn't actually run the command, and it doesn't properly quote the script name (meaning it breaks on paths with spaces). I'm using the following successfully: "c:\windows\system32\windowspowershell\v1.0\powershell.exe" -noexit -command "& '%1'" – Hardboiled

An alternative context-menu command which doesn't use the "runas" key, and which preserves the current directory (see section 2 of the answer): https://mcmap.net/q/22623/-how-to-start-powershell-script-from-bat-file-with-proper-working-directory – Guardado

Answer 9

The code posted by Jonathan and Shay Levy did not work for me.

Please find the working code below:

If (-NOT ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator"))
{   
#"No Administrative rights, it will display a popup window asking user for Admin rights"

$arguments = "& '" + $myinvocation.mycommand.definition + "'"
Start-Process "$psHome\powershell.exe" -Verb runAs -ArgumentList $arguments

break
}
#"After user clicked Yes on the popup, your file will be reopened with Admin rights"
#"Put your code here"

Neckwear

Very useful and pratical solution: just perpended it to my script and it works. – Spires

@Abatonime How about you point out easy to miss differences for the benefit of your readers instead? Honestly, that change isn't worth more than a comment on the other answer. – Approve

Answer 10

You need to rerun the script with administrative privileges and check if the script was launched in that mode. Below I have written a script that has two functions: DoElevatedOperations and DoStandardOperations. You should place your code that requires admin rights into the first one and standard operations into the second. The IsRunAsAdmin variable is used to identify the admin mode.

My code is an simplified extract from the Microsoft script that is automatically generated when you create an app package for Windows Store apps.

param(
    [switch]$IsRunAsAdmin = $false
)

# Get our script path
$ScriptPath = (Get-Variable MyInvocation).Value.MyCommand.Path

#
# Launches an elevated process running the current script to perform tasks
# that require administrative privileges.  This function waits until the
# elevated process terminates.
#
function LaunchElevated
{
    # Set up command line arguments to the elevated process
    $RelaunchArgs = '-ExecutionPolicy Unrestricted -file "' + $ScriptPath + '" -IsRunAsAdmin'

    # Launch the process and wait for it to finish
    try
    {
        $AdminProcess = Start-Process "$PsHome\PowerShell.exe" -Verb RunAs -ArgumentList $RelaunchArgs -PassThru
    }
    catch
    {
        $Error[0] # Dump details about the last error
        exit 1
    }

    # Wait until the elevated process terminates
    while (!($AdminProcess.HasExited))
    {
        Start-Sleep -Seconds 2
    }
}

function DoElevatedOperations
{
    Write-Host "Do elevated operations"
}

function DoStandardOperations
{
    Write-Host "Do standard operations"

    LaunchElevated
}


#
# Main script entry point
#

if ($IsRunAsAdmin)
{
    DoElevatedOperations
}
else
{
    DoStandardOperations
}

Garment

Answer 11

You can also force the application to open as administrator, if you have an administrator account, of course.

Locate the file, right click > properties > Shortcut > Advanced and check Run as Administrator

Then Click OK.

Graveyard

How do you script this? – Scirrhus

Something like this... haven't tested it... update with your values runas /user:\"COMPUTER-NAME\\ADMIN-USER\" \"C:\\PATH\\TO\\PROGRAM.EXE\" – Graveyard

Answer 12

Adding my 2 cents. My simple version based on net session which works all the time so far in Windows 7 / Windows 10. Why over complicate it?

if (!(net session)) {$path =  "& '" + $myinvocation.mycommand.definition + "'" ; Start-Process powershell -Verb runAs -ArgumentList $path ; exit}

just add to the top of the script and it will run as administrator.

Brigham

is there a way to put a message to the user after the "Access is denied" is displayed? – Langsyne

... or to avoid the message at all – Cristobalcristobalite

@GünterZöchbauer if (!(net session 2>&1 | Out-Null)) { ... @Langsyne ... } else { echo "your message" }. – Spinel

getting errors for this, cannot be loaded because running scripts is disabled on this system. For more information, see about_Execution_Policies at https:/go.microsoft.com/fwlink/?LinkID=135170. – Eductive

@Eductive do what it says – Rogation

@Rogation Please add more information, it's unclear as how and why you say this, stackoverflow does not typically build on 'authoritarian' arguments – Eductive

@Eductive Set-ExecutionPolicy -ExecutionPolicy <PolicyName>, You can set it to bypass But bypass may be dangerous. Set it to AllSigned – Rogation

Answer 13

This behavior is by design. There are multiple layers of security since Microsoft really didn't want .ps1 files to be the latest email virus. Some people find this to be counter to the very notion of task automation, which is fair. The Vista+ security model is to "de-automate" things, thus making the user okay them.

However, I suspect if you launch powershell itself as elevated, it should be able to run batch files without requesting the password again until you close powershell.

Pintsize

You CANNOT launch PowerShell elevated from the Run Command, unless you run this first: – Antineutron

Answer 14

A number of the answers here are close, but a little more work than needed.

Create a shortcut to your script and configure it to "Run as Administrator":

• Create the shortcut.
• Right-click shortcut and open Properties...
• Edit Target from <script-path> to powershell <script-path>
• Click Advanced... and enable Run as administrator

Anabolite

Answer 15

Here is how to run a elevated powershell command and collect its output form within a windows batch file in a single command(i.e not writing a ps1 powershell script).

powershell -Command 'Start-Process powershell -ArgumentList "-Command (Get-Process postgres | Select-Object Path | Select-Object -Index 0).Path | Out-File -encoding ASCII $env:TEMP\camp-postgres.tmp" -Verb RunAs'

Above you see i first launch a powershell with elevated prompt and then ask that to launch another powershell(sub shell) to run the command.

Spaceless

Answer 16

I have found a way to do this...

Create a batch file to open your script:

@echo off
START "" "C:\Scripts\ScriptName.ps1"

Then create a shortcut, on your desktop say (right click New -> Shortcut).

Then paste this into the location:

C:\Windows\System32\runas.exe /savecred /user:*DOMAIN*\*ADMIN USERNAME* C:\Scripts\BatchFileName.bat

When first opening, you will have to enter your password once. This will then save it in the Windows credential manager.

After this you should then be able to run as administrator without having to enter a administrator username or password.

Klepht

/savecred is not safe! – Carl

This is the only solution that doesn't use the graphical elevation prompt that might not be accessible on a remote session. – Lesleelesley

Answer 17

C:\Users\"username"\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Windows PowerShell is where the shortcut of PowerShell resides. It too still goes to a different location to invoke the actual 'exe' (%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe).

Since PowerShell is user-profile driven when permissions are concerned; if your username/profile has the permissions to do something then under that profile, in PowerShell you would generally be able to do it as well. That being said, it would make sense that you would alter the shortcut located under your user profile, for example, C:\Users\"username"\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Windows PowerShell.

Right-click and click properties. Click "Advanced" button under the "Shortcut" tab located right below the "Comments" text field adjacent to the right of two other buttons, "Open File Location" and "Change Icon", respectively.

Check the checkbox that reads, "Run as Administrator". Click OK, then Apply and OK. Once again right click the icon labeled 'Windows PowerShell' located in C:\Users\"username"\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Windows PowerShell and select "Pin to Start Menu/Taskbar".

Now whenever you click that icon, it will invoke the UAC for escalation. After selecting 'YES', you will notice the PowerShell console open and it will be labeled "Administrator" on the top of the screen.

To go a step further... you could right click that same icon shortcut in your profile location of Windows PowerShell and assign a keyboard shortcut that will do the exact same thing as if you clicked the recently added icon. So where it says "Shortcut Key" put in a keyboard key/button combination like: Ctrl + Alt + PP (for PowerShell). Click Apply and OK.

Now all you have to do is press that button combination you assigned and you will see UAC get invoked, and after you select 'YES' you will see a PowerShell console appear and "Administrator" displayed on the title bar.

Underthecounter

Dude :) The keyword in OP's question is scripting!! Not some UI mouse clicking solution. – Caldwell

Answer 18

I am using the solution below. It handles stdout/stderr via transcript feature and passes exit code correctly to parent process. You need to adjust transcript path/filename.

If (-NOT ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator"))
{ 
  echo "* Respawning PowerShell child process with elevated privileges"
  $pinfo = New-Object System.Diagnostics.ProcessStartInfo
  $pinfo.FileName = "powershell"
  $pinfo.Arguments = "& '" + $myinvocation.mycommand.definition + "'"
  $pinfo.Verb = "RunAs"
  $pinfo.RedirectStandardError = $false
  $pinfo.RedirectStandardOutput = $false
  $pinfo.UseShellExecute = $true
  $p = New-Object System.Diagnostics.Process
  $p.StartInfo = $pinfo
  $p.Start() | Out-Null
  $p.WaitForExit()
  echo "* Child process finished"
  type "C:/jenkins/transcript.txt"
  Remove-Item "C:/jenkins/transcript.txt"
  Exit $p.ExitCode
} Else {
  echo "Child process starting with admin privileges"
  Start-Transcript -Path "C:/jenkins/transcript.txt"
}

# Rest of your script goes here, it will be executed with elevated privileges

Kimberly

This loses all invocation arguments – Kinakinabalu

Answer 19

The problem with the @pgk and @Andrew Odri's answers is when you have script parameters, specially when they are mandatory. You can solve this problem using the following approach:

1. The user right-clicks the .ps1 file and selects 'Run with PowerShell': ask him for the parameters through input boxes (this is a much better option than use the HelpMessage parameter attribute);
2. The user executes the script through the console: allow him to pass the desired parameters and let the console force him to inform the mandatory ones.

Here is how would be the code if the script had the ComputerName and Port mandatory parameters:

[CmdletBinding(DefaultParametersetName='RunWithPowerShellContextMenu')]
param (
    [parameter(ParameterSetName='CallFromCommandLine')]
    [switch] $CallFromCommandLine,

    [parameter(Mandatory=$false, ParameterSetName='RunWithPowerShellContextMenu')]
    [parameter(Mandatory=$true, ParameterSetName='CallFromCommandLine')]
    [string] $ComputerName,

    [parameter(Mandatory=$false, ParameterSetName='RunWithPowerShellContextMenu')]
    [parameter(Mandatory=$true, ParameterSetName='CallFromCommandLine')]
    [UInt16] $Port
)

function Assert-AdministrativePrivileges([bool] $CalledFromRunWithPowerShellMenu)
{
    $isAdministrator = ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)

    if ($isAdministrator)
    {
        if (!$CalledFromRunWithPowerShellMenu -and !$CallFromCommandLine)
        {
            # Must call itself asking for obligatory parameters
            & "$PSCommandPath" @script:PSBoundParameters -CallFromCommandLine
            Exit
        }
    }
    else
    {
        if (!$CalledFromRunWithPowerShellMenu -and !$CallFromCommandLine)
        {
            $serializedParams = [Management.Automation.PSSerializer]::Serialize($script:PSBoundParameters)

            $scriptStr = @"
                `$serializedParams = '$($serializedParams -replace "'", "''")'

                `$params = [Management.Automation.PSSerializer]::Deserialize(`$serializedParams)

                & "$PSCommandPath" @params -CallFromCommandLine
"@

            $scriptBytes = [System.Text.Encoding]::Unicode.GetBytes($scriptStr)
            $encodedCommand = [Convert]::ToBase64String($scriptBytes)

            # If this script is called from another one, the execution flow must wait for this script to finish.
            Start-Process -FilePath 'powershell' -ArgumentList "-ExecutionPolicy Bypass -NoProfile -EncodedCommand $encodedCommand" -Verb 'RunAs' -Wait
        }
        else
        {
            # When you use the "Run with PowerShell" feature, the Windows PowerShell console window appears only briefly.
            # The NoExit option makes the window stay visible, so the user can see the script result.
            Start-Process -FilePath 'powershell' -ArgumentList "-ExecutionPolicy Bypass -NoProfile -NoExit -File ""$PSCommandPath""" -Verb 'RunAs'
        }

        Exit
    }
}

function Get-UserParameters()
{
    [string] $script:ComputerName = [Microsoft.VisualBasic.Interaction]::InputBox('Enter a computer name:', 'Testing Network Connection')

    if ($script:ComputerName -eq '')
    {
        throw 'The computer name is required.'
    }

    [string] $inputPort = [Microsoft.VisualBasic.Interaction]::InputBox('Enter a TCP port:', 'Testing Network Connection')

    if ($inputPort -ne '')
    {
        if (-not [UInt16]::TryParse($inputPort, [ref]$script:Port))
        {
            throw "The value '$inputPort' is invalid for a port number."
        }
    }
    else
    {
        throw 'The TCP port is required.'
    }
}

# $MyInvocation.Line is empty in the second script execution, when a new powershell session
# is started for this script via Start-Process with the -File option.
$calledFromRunWithPowerShellMenu = $MyInvocation.Line -eq '' -or $MyInvocation.Line.StartsWith('if((Get-ExecutionPolicy')

Assert-AdministrativePrivileges $calledFromRunWithPowerShellMenu

# Necessary for InputBox
[System.Reflection.Assembly]::Load('Microsoft.VisualBasic, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a') | Out-Null

if ($calledFromRunWithPowerShellMenu)
{
    Get-UserParameters
}

# ... script code
Test-NetConnection -ComputerName $ComputerName -Port $Port

Venusian

Answer 20

Another simpler solution is that you may also right click on "C:\Windows\System32\cmd.exe" and choose "Run as Administrator" then you can run any app as administrator without providing any password.

Horick

Answer 21

I recently needed this to build an environment on ansible. I say right away - the decision is not mine, but I don’t remember where I got it. Looks like that:

powershell.exe -NoProfile -ExecutionPolicy Unrestricted -Command "& {Start-Process PowerShell -ArgumentList '-NoProfile -ExecutionPolicy Unrestricted -Command Get-Service -Name ssh-agent | Set-Service -StartupType Automatic' -Verb RunAs}";

This example enables ssh-agent autostart. The required command is specified after -Command. The only problem is the launch happens on a new PS instance, but so far this is the only way that I know to execute the command as an admin without additional steps.

Milesmilesian

Answer 22

The most reliable way I've found is to wrap it in a self-elevating .bat file:

@echo off
NET SESSION 1>NUL 2>NUL
IF %ERRORLEVEL% EQU 0 GOTO ADMINTASKS
CD %~dp0
MSHTA "javascript: var shell = new ActiveXObject('shell.application'); shell.ShellExecute('%~nx0', '', '', 'runas', 0); close();"
EXIT

:ADMINTASKS

powershell -file "c:\users\joecoder\scripts\admin_tasks.ps1"

EXIT

The .bat checks if you're already admin and relaunches the script as Administrator if needed. It also prevents extraneous "cmd" windows from opening with the 4th parameter of ShellExecute() set to 0.

Aesthetic

Good answer, but I tried it and didn't work (and exited the command line from which I called it). I fixed this way: I changed the first EXIT to a GOTO :EOF and deleted the second. Also, the cd %~dp0 should be cd /d %~dp0 AND placed the first command after the @echo off. This way you don't need the absolute path of the .ps1 either, just place it in the same folder that the .bat. If you need to see the result, change the 4th parameter to 1. – Elishaelision

Which O/S and version are you running? – Aesthetic

Windows 7 SP1 Ultimate. I have system in C: but also data and portable applications in D: mainly (and several other drives). By the way... what if the program/script use parameters? What would be the mshta command? – Elishaelision

I think you may have errored in your testing, because the script works just fine. By the way, it's designed to exit the calling cmd process so that's not "fixing" it, but I'm glad you were able to modify it according to your needs. – Aesthetic

Ok if you want to exit the cmd (I didn't). But regarding the other changes, I think are fixes because my version would work for both of us while yours doesn't for me, i.e. mine's more general (address the scenario of different drives). Anyway, a very clever approach. – Elishaelision

Answer 23

Existing answers lacked arguments and working directory passthrough.

Here is my snippet:

if (!([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")) {
    Write-Host "Running as non-administrator, restarting as administrator..."
    $powershell = if($PSVersionTable.PSVersion.Major -gt 5) { "pwsh.exe" } else { "powershell.exe" }
    $arguments = ($PsBoundParameters.GetEnumerator() | ForEach-Object { "-$($_.Key) `"$($_.Value)`"" }) -join " "
    Start-Process $powershell  -WorkingDirectory (Get-Location) -Verb RunAs -Wait "-NoProfile -ExecutionPolicy Bypass -File `"$PSCommandPath`" $arguments"; exit 
} 

Hobbs

Answer 24

On top of Shay Levy's answer, follow the below setup (just once)

1. Start a PowerShell with Administrator rights.
2. Follow Stack Overflow question PowerShell says “execution of scripts is disabled on this system.”.
3. Put your .ps1 file in any of the PATH folders, for example. Windows\System32 folder

After the setup:

1. Press Win + R
2. Invoke powershell Start-Process powershell -Verb runAs <ps1_file>

You can now run everything in just one command line. The above works on Windows 8 Basic 64-bit.

Lingle

Answer 25

I haven't seen my own way of doing it before, so, try this out. It is way easier to follow and has a much smaller footprint:

if([bool]([Security.Principal.WindowsIdentity]::GetCurrent()).Groups -notcontains "S-1-5-32-544") {
    Start Powershell -ArgumentList "& '$MyInvocation.MyCommand.Path'" -Verb runas
    }

Very simply, if the current Powershell session was called with administrator privileges, the Administrator Group well-known SID will show up in the Groups when you grab the current identity. Even if the account is a member of that group, the SID won't show up unless the process was invoked with elevated credentials.

Nearly all of these answers are a variation on Microsoft's Ben Armstrong's immensely popular method of how to accomplish it while not really grasping what it is actually doing and how else to emulate the same routine.

Grateful

Answer 26

To append the output of the command to a text filename which includes the current date you can do something like this:

$winupdfile = 'Windows-Update-' + $(get-date -f MM-dd-yyyy) + '.txt'
if (!([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")) { Start-Process powershell.exe "-NoProfile -ExecutionPolicy Bypass -Command `"Get-WUInstall -AcceptAll | Out-File $env:USERPROFILE\$winupdfile -Append`"" -Verb RunAs; exit } else { Start-Process powershell.exe "-NoProfile -ExecutionPolicy Bypass -Command `"Get-WUInstall -AcceptAll | Out-File $env:USERPROFILE\$winupdfile -Append`""; exit }

Perique

Answer 27

This is a clarification ...

The powershell RUNAS / SAVECRED credential "is not safe", tried it and it adds the admin identity and password into the credential cache and can be used elsewhere OOPS!. If you have done this I suggest you check and remove the entry.

Review your program or code because the Microsoft policy is you cannot have mixed user and admin code in the same code blob without the UAC (the entry point) to execute the program as admin. This would be sudo (same thing) on Linux.

The UAC has 3 types, dont'see, a prompt or an entry point generated in the manifest of the program. It does not elevate the program so if there is no UAC and it needs admin it will fail. The UAC though as an administrator requirement is good, it prevents code execution without authentication and prevents the mixed codes scenario executing at user level.

Mingmingche

This should be a comment, it is not a solution to the question (just the way the forum works; your content is useful, but is not a solution). – Delora

Answer 28

Elevated PowerShell from Start>Run

You cannot run elevated powershell from the "run" command, in 2012R2 or 2016, without shelling twice:

C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell -Command "saps PowerShell -Verb RunAs "

Antineutron

Answer 29

It turns out it was too easy. All you have to do is run a cmd as administrator. Then type explorer.exe and hit enter. That opens up Windows Explorer. Now right click on your PowerShell script that you want to run, choose "run with PowerShell" which will launch it in PowerShell in administrator mode.

It may ask you to enable the policy to run, type Y and hit enter. Now the script will run in PowerShell as administrator. In case it runs all red, that means your policy didn't take affect yet. Then try again and it should work fine.

Waggoner

Not sure what version of Windows you're running, but on Windows 10, at least, invoking explorer.exe from an elevated command prompt won't open an elevated explorer process, unless you terminate all currently-running explorer processes first. – Superannuate

C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell -Command "saps PowerShell -Verb RunAs " – Antineutron