ChatGPT解决这个技术问题 Extra ChatGPT

Why are my PowerShell scripts not running?

I wrote a simple batch file as a PowerShell script, and I am getting errors when they run.

It's in a scripts directory in my path. This is the error I get:

Cannot be loaded because the execution of scripts is disabled on this system. Please see "get-help about-signing".

I looked in the help, but it's less than helpful.


T
TylerH

It could be PowerShell's default security level, which (IIRC) will only run signed scripts.

Try typing this:

set-executionpolicy remotesigned

That will tell PowerShell to allow local (that is, on a local drive) unsigned scripts to run.

Then try executing your script again.


You have to run Powershell with administrator privileges, at least under Windows 8!
And you have to run the PowerShell script with administrative privileges under Windows 7 as well.
This is a fairly terrifying answer. For one, it permanently changes Powershell's default security level in possibly undesirable (and insecure) ways. For another, it fails to even adequately explain that signed remote scripts and unsigned local scripts – but not unsigned remote scripts, which Chocolatey occasionally requires – will be granted execution privileges. Most users probably want this and this instead.
While Cecil's concern over some weaknesses in the answer are fair, I wanted to point out a few things. 1) His two links appear to open the same page for me. 2) If you want scripts to simply run, setting the execution policy is probably still the way to go, and possibly unrelated to OP: 3) it seems the best policy is for startup scripts, specify the execution policy and scope in the command line running the script, and for logon set the session configuration as needed. If you want high security during the Windows session but reduced for logon, you'd want to get nuanced in your script order.
For one-shots, I find Ankur's answer below that defines a temporary exception for the running PowerShell instance the most helpful.
T
TylerH

You need to run Set-ExecutionPolicy:

Set-ExecutionPolicy Restricted <-- Will not allow any powershell scripts to run.  Only individual commands may be run.

Set-ExecutionPolicy AllSigned <-- Will allow signed powershell scripts to run.

Set-ExecutionPolicy RemoteSigned <-- Allows unsigned local script and signed remote powershell scripts to run.

Set-ExecutionPolicy Unrestricted <-- Will allow unsigned powershell scripts to run.  Warns before running downloaded scripts.

Set-ExecutionPolicy Bypass <-- Nothing is blocked and there are no warnings or prompts.

What's the default ExecutionPolicy value that Windows sets a new installation to?
@MatthewLock Restricted is the default policy. Read More
P
Peter Mortensen

Use:

Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process

Always use the above command to enable to executing PowerShell in the current session.


this + superuser.com/questions/612409/… + shorcut link = perfection
P
Peter Mortensen

I was able to bypass this error by invoking PowerShell like this:

powershell -executionpolicy bypass -File .\MYSCRIPT.ps1

That is, I added the -executionpolicy bypass to the way I invoked the script.

This worked on Windows 7 Service Pack 1. I am new to PowerShell, so there could be caveats to doing that that I am not aware of.

[Edit 2017-06-26] I have continued to use this technique on other systems including Windows 10 and Windows 2012 R2 without issue.

Here is what I am using now. This keeps me from accidentally running the script by clicking on it. When I run it in the scheduler I add one argument: "scheduler" and that bypasses the prompt.

This also pauses the window at the end so I can see the output of PowerShell.

if NOT "%1" == "scheduler" (
   @echo looks like you started the script by clicking on it.
   @echo press space to continue or control C to exit.
   pause
)

C:
cd \Scripts

powershell -executionpolicy bypass -File .\rundps.ps1

set psexitcode=%errorlevel%

if NOT "%1" == "scheduler" (
   @echo Powershell finished.  Press space to exit.
   pause
)

exit /b %psexitcode%

This is what chocolatey uses to download and install chocolatey
I tried running the command Set-ExecutionPolicy bypass -File C:\Users\david\Desktop\test.ps1 and got an error message. There is no -File option for this command.
Oh, I see. You have to make a shortcut containing the command powershell -executionpolicy bypass -File C:\Users\david\Desktop\test.ps1 . The command test.ps1 is then run even when the safe global command Set-ExecutionPolicy Restricted has been given. I hope this basic information helps someone.
h
hackjutsu
Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process

The above command worked for me even when the following error happens:

Access to the registry key 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell' is denied.

d
danday74

Also it's worth knowing that you may need to include .\ in front of the script name. For example:

.\scriptname.ps1

B
Brian Mains

The command set-executionpolicy unrestricted will allow any script you create to run as the logged in user. Just be sure to set the executionpolicy setting back to signed using the set-executionpolicy signed command prior to logging out.


set-executionpolicy signed gives Cannot bind parameter 'ExecutionPolicy' etc.
W
Wasif

We can bypass execution policy in a nice way (inside command prompt):

type file.ps1 | powershell -command -

Or inside powershell:

gc file.ps1|powershell -c -

M
MaartenDev

On Windows 10: Click change security property of myfile.ps1 and change "allow access" by right click / properties on myfile.ps1


C
Christian Brüggemann

It would be ideal to bypass execution policies e.g. through

powershell -executionpolicy bypass -File .\MYSCRIPT.ps1

Unfortunately this can still be prevented by group policies. As a workaround, you can encode your script as Base64 by running this in PowerShell:

[Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes((Get-Content .\MYSCRIPT.ps1)))

Then execute the result like this:

powershell.exe -EncodedCommand "put-your-base64-string-here"

Caveat: This won't work with scripts that require parameters.