Launch powershell as admin when double click on ps1 file

I have read How to open a file for editing in Administrator mode?

I have a .ps1 file which needs to run as administrator. I'm happy to have it that when I double click on any .ps1 file, powershell runs as an admin.

I've gone to C:\Users\me\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Windows PowerShell and made both the PowerShell shortcuts to run as admin

If I open Powershell from the start menu, I'm asked if I want to allow the app to make changes... This shows it's running as Admin, coupled with when Powershell is running it displays Administrator in the 'title' bar

However, when I double click on a .ps1 file, it opens as a normal user (not admin).

What else do I do need to do?

4 Answers

This will not execute the script when you double-click on it, but this will execute itself as elevated when you run it. You can try this:

$principal = New-Object Security.Principal.WindowsPrincipal([Security.Principal.WindowsIdentity]::GetCurrent())
if($principal.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) { # code here...
}
else { Start-Process -FilePath "powershell" -ArgumentList "$('-File ""')$(Get-Location)$('\')$($MyInvocation.MyCommand.Name)$('""')" -Verb runAs
}

With this, the non-elevated console will exit.

.ps1 are by default associated with Notepad.exe by design. Double-click will simply open the .ps1 in notepad for review or editing. This was a conscious security decision from MS.

Windows PowerShell Securing the Shell

Of course you can change that association to powershell.exe, but again, you are exposing yourself to unnecessary risks. If this is in an enterprise, your security team may have words for you and or this could end up being and RPE (resume producing event).

All that being said. It does not matter what you do to the shortcuts, that is not how double-click would work.

Double-click, does not start a shortcut, it starts with the associated app, in the case...

%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe

If you have scripts that require admin privs/or you want to run as admin, then you have to code in the script to re-launch as admin, if it was not started that way. Now, this does mean you'll end up in a new PoSH session vs the one you started in, and this is by design.

Again, changing the file association to auto-execute, is just bad practice and subjects you to the same risks from the legacy .vbscript days.

Copy/paste your powershell shortcut to a place where you would like to launch the script from. Right-click the new shortcut, click properties, and then advanced and make sure it's set to run as administrator. Then, in the in the target box type the path to and name of the script after powershell.exe

%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe c:\myscripts\my-awesome-script.ps1

Make sure you use "quotes" around your addition if there are any spaces in the path or filename like:

"c:\my scripts\some script with spaces.ps1"

This will launch a new powershell as an administrator and start the script automatically in the new shell.

You'll probably also want to rename the shortcut to indicate that it's for a specific script, instead of a regular powershell session. Right-click, rename.

Explanation

Windows don't allow PowerShell script to run natively, you need to update the execution policy for your user or a selected user to use them.

Answer

1. Open your PowerShell (In admin mode if needed)
2. Change the execution policy Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

3. Type Get-Execution -List to see all execution policy

    Scope ExecutionPolicy ----- ---------------
   MachinePolicy Unrestricted
   UserPolicy Undefined
   Process Undefined
   CurrentUser RemoteSigned
   LocalMachine Unrestricted

If this still doesn't work you can use Windows PowerShell ISE which is the PowerShell IDE

1. Right-click on your *.ps1 file
2. Open With → Windows PowerShell ISE

Or simply open ISE first.

Security

Microsoft doesn't allow you to run PowerShell script by default for serious security reason, someone could easily run a script on your computer and have full access! To avoid that please set your execution policy back to what they were.

Microsoft documentation