ChatGPT解决这个技术问题 Extra ChatGPT

Why is my locally-created script not allowed to run under the RemoteSigned execution policy?

Since this question continues to attract responses that are either refuted by the question body or don't address the actual problem, please read this simple summary of what you need to know: This is not a "Why won't my default installation of PowerShell run scripts?" question. This is not a "Why won't my installation of PowerShell run scripts downloaded from the internet?" question. The question is why the RemoteSigned execution policy is preventing script execution when it shouldn't. RemoteSigned is the only execution policy I want to use. I am aware that other, less-restrictive policies are available. If those policies were acceptable substitutes I would have just used them instead and this question wouldn't exist. The execution policy is already set to RemoteSigned. Changing it from RemoteSigned to RemoteSigned is not a solution. The script file is created and stored locally. The script file is not blocked. The script file was never blocked (see previous point). The script file cannot be unblocked because there is nothing to unblock (see previous point). The script file is (attempted to be) executed by an administrator. Windows PowerShell is the only application involved. Not Windows PowerShell ISE nor Command Prompt nor any other tools or editors are relevant. The cause of the problem has already been identified (see accepted answer). After nearly 8 years, I think all other obvious explanations, whether applicable or not, have been posted, too. If you think otherwise then please read the question and existing answers in their entirety before adding yours.

I am using Windows PowerShell 2.0 on 64-bit Windows 7 Professional. I have a script on my Desktop that causes the following error when I try to run it:

File C:\Users\UserName\Desktop\Script.ps1 cannot be loaded. The file C:\Users\UserName\Desktop\Script.ps1 is not digitally signed. The script will not execute on the system.  Please see "get-help about_signing" for more details..
At line:1 char:54
+ C:\Users\UserName\Desktop\TestGetWindowsUpdateLog.ps1 <<<<
    + CategoryInfo          : NotSpecified: (:) [], PSSecurityException
    + FullyQualifiedErrorId : RuntimeException

I am both a domain administrator and a local administrator, and if I run Get-ExecutionPolicy -List, I can see that the Group Policy Object I created to configure PowerShell is correctly applying the RemoteSigned execution policy at the machine level:

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

I created the script myself in Notepad, and used the Sysinternals' streams utility and the file Properties dialog to confirm that the script is not being treated as having come from the internet. If I copy the script to a network share on a domain server, then it's allowed to execute. If I run Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope LocalMachine then the local script is still not allowed to execute, which makes sense since the execution policy at the MachinePolicy scope will take precedence.

As documented by about_Execution_Policies(current; at time of question), the RemoteSigned policy means:

Scripts can run. Requires a digital signature from a trusted publisher on scripts and configuration files that are downloaded from the Internet (including e-mail and instant messaging programs). Does not require digital signatures on scripts that you have run and that you have written on the local computer (not downloaded from the Internet). Risks running unsigned scripts from sources other than the Internet and signed, but malicious, scripts.

My script is not signed, but since it is both created and executed locally, it should satisfy the third bullet point above. Therefore...

Why is my script not being allowed to run?

Why does PowerShell complain that my script "is not digitally signed" when that requirement should only apply to files from the Internet?

Why does PowerShell no longer care about the script not being signed when it's run from a network share?

@Downvoter: care to give a reason why?

A
Andy Arismendi

Some things to check:

Can you change to unrestricted?

Set-ExecutionPolicy Unrestricted

Is the group policy set?

Computer Configuration\Administrative Templates\Windows Components\Windows PowerShell

User Configuration\Administrative Templates\Windows Components\Windows PowerShell

Also, how are you calling Script.ps1?

Does this allow it to run?

powershell.exe -executionpolicy bypass -file .\Script.ps1

The default value for the Scope parameter is LocalMachine, so Set-ExecutionPolicy Unrestricted is effectively the same as the Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope LocalMachine I'd already tried. Yes, the Turn on Script Execution policy is enabled for Computer Configuration. PowerShell opens to C:\Users\UserName, so I just run .\Desktop\Script.ps1 at the prompt. Using the absolute path yields the same error, as does calling the script via powershell.exe.
Have you tried disabling the group policy setting and refreshing with gpupdate /force? (Relaunch PowerShell.exe after)
Well, for a long while I was running as Unrestricted at the LocalMachine scope, but when I started writing scripts I wanted to run from other computers I set LocalMachine back to Undefined and added the current Group Policy to set RemoteSigned at the MachinePolicy scope. This is just a one-off test script and it's really no big deal to run it from the network instead, I just want to know why it doesn't work locally. After all, a locally-created script should be allowed to execute under RemoteSigned, right? I just thought there must be something I'm missing or not understanding.
@BACON You are correct about RemoteSigned saving Write-Host hi with notepad to your desktop should run fine. You're configuration looks ok too... Something seems broken to me... which is why I suggested removing the group policy to see if it helps.
For development, we just used -executionpolicy bypass to temporarily get past the remotesigned issue... and that let us uncover & debug other issues (unrelated, that required us to upgrade PowerShell).
O
O-Dogg

Is the file being blocked? I had the same issue and was able to resolve it by right clicking the .PS1 file, Properties and choosing Unblock.


As I explained, the script is being created directly on my hard drive (not downloaded from anywhere), and I confirmed there are no alternate streams identifying it as originating from a different zone (like Internet Explorer and other web browsers create). If I run 'Write-Host ''Hello, World!'';' > .\Test.ps1; .\Test.ps1; I still get the error that the script is not digitally signed and it is not executed. If I open the Properties dialog for the newly-created file there is nothing to unblock.
What do you mean ~"Properties and choosing Unblock"?
@IgorGanapolsky they mean in the Explorer, find the ps1 file right click on it to bring up the context menu and choose Properties, on the first tab near the bottom it will say the file is blocked and allow you to tick a checkbox to unblock it.
Note that if you downloaded a zip file, you should unblock the zip file before extracting it to avoid mass-unblocking all the files inside it.
@Lankymart Windows 10, tried this, does not say it is blocked.
G
GeekMustHave

I have found out when running a PS1 file for a Mapped drive to Dropbox that I'm always getting this error. When opening up properties for the PS1 there is no "Unblock".

The only thing that work for me is

powershell.exe -executionpolicy bypass -file .\Script.ps1


You're saying your script is stored on a drive mapped to a network share? Or the script creates a mapped drive? If the former, as it states in the body and title of the question, the script was created and stored locally, so the origin/zone of the script would not be a factor. Either way, using the Bypass execution policy has already been suggested over five years ago and as recently as five months ago. Please read the question and existing answers before answering.
G
Gautam Sharma

When you run a .ps1 PowerShell script you might get the message saying “.ps1 is not digitally signed. The script will not execute on the system.” To fix it you have to run the command below to run Set-ExecutionPolicy and change the Execution Policy setting.

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

Another answer already suggests using the Bypass execution policy. Using a different policy isn't helpful, anyways, and doesn't address the actual issue if RemoteSigned really is what's needed. Finally, the error message you reference is not the same one as in the question.
Also, this command only works for the current session
L
Lance U. Matthews

I finally tracked this down to .NET Code Access Security. I have some internally-developed binary modules that are stored on and executed from a network share. To get .NET 2.0/PowerShell 2.0 to load them, I had added a URL rule to the Intranet code group to trust that directory:

PS> & "$Env:SystemRoot\Microsoft.NET\Framework64\v2.0.50727\caspol.exe" -machine -listgroups
Microsoft (R) .NET Framework CasPol 2.0.50727.5420
Copyright (c) Microsoft Corporation.  All rights reserved.

Security is ON
Execution checking is ON
Policy change prompt is ON

Level = Machine

Code Groups:

1.  All code: Nothing
    1.1.  Zone - MyComputer: FullTrust
        1.1.1.  StrongName - ...: FullTrust
        1.1.2.  StrongName - ...: FullTrust
    1.2.  Zone - Intranet: LocalIntranet
        1.2.1.  All code: Same site Web
        1.2.2.  All code: Same directory FileIO - 'Read, PathDiscovery'
        1.2.3.  Url - file://Server/Share/Directory/WindowsPowerShell/Modules/*: FullTrust
    1.3.  Zone - Internet: Internet
        1.3.1.  All code: Same site Web
    1.4.  Zone - Untrusted: Nothing
    1.5.  Zone - Trusted: Internet
        1.5.1.  All code: Same site Web

Note that, depending on which versions of .NET are installed and whether it's 32- or 64-bit Windows, caspol.exe can exist in the following locations, each with their own security configuration (security.config):

$Env:SystemRoot\Microsoft.NET\Framework\v2.0.50727\

$Env:SystemRoot\Microsoft.NET\Framework64\v2.0.50727\

$Env:SystemRoot\Microsoft.NET\Framework\v4.0.30319\

$Env:SystemRoot\Microsoft.NET\Framework64\v4.0.30319\

After deleting group 1.2.3....

PS> & "$Env:SystemRoot\Microsoft.NET\Framework64\v2.0.50727\caspol.exe" -machine -remgroup 1.2.3.
Microsoft (R) .NET Framework CasPol 2.0.50727.9136
Copyright (c) Microsoft Corporation.  All rights reserved.

The operation you are performing will alter security policy.
Are you sure you want to perform this operation? (yes/no)
yes
Removed code group from the Machine level.
Success

...I am left with the default CAS configuration and local scripts now work again. It's been a while since I've tinkered with CAS, and I'm not sure why my rule would seem to interfere with those granting FullTrust to MyComputer, but since CAS is deprecated as of .NET 4.0 (on which PowerShell 3.0 is based), I guess it's a moot point now.


How did you add a URL rule? I had the same issue and hoping this can help me solving it. Thanks.
It's been a very long time since I've worked with caspol.exe, but after running caspol.exe -machine -addgroup 1.2 -url file://Server/Share/Directory/WindowsPowerShell/Modules/* FullTrust I ended up with the same 1.2.3. rule seen in this answer. I was using a file:// URL to reference a directory on an SMB share, though I see in the documentation one of the -addgroup examples uses a UNC path.
I dont have this internet thing on any of my 4 caspol.exe so this is not the solution
@Charkel What is the problem you're having? The same one described in the question with the same error message? This fixed the bizarre and unexpected behavior I was experiencing, which is why I marked it as the solution.
P
Peter Mortensen

If the file is copied from a network location, that is, another computer, Windows might have blocked that file. Right click on the file and click on the unblock button and see if it works.


As I explained in both the question and my comment on @O-Dogg's answer, the script was being created directly on my hard drive (not downloaded from anywhere), and I confirmed there were no alternate streams identifying it as originating from a different zone (like Internet Explorer and other web browsers create). If I ran 'Write-Host ''Hello, World!'';' > .\Test.ps1; .\Test.ps1; I still got the error that the script was not digitally signed and it was not executed. If I opened the Properties dialog for the newly-created file there was nothing to unblock.
Worth checking that you aren't creating and running it on a mapped drive. On our servers for example the home folder for each user is a mapped drive to their personal folder.
l
leonidaa

this code line was working in Ubuntu with virtualbox and with Win 10 as a virtual os , inside of the powershell

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

If it is not working I recomand to read this resources below :

Set-ExecutionPolicy

Module: Microsoft.PowerShell.Security Sets the PowerShell execution policies for Windows computers.

https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.security/set-executionpolicy?view=powershell-7.1#:~:text=To%20change%20the%20execution%20policy,Get%2DExecutionPolicy%20with%20no%20parameters.

https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.security/get-executionpolicy?view=powershell-7.1

Get-ExecutionPolicy -List

https://devblogs.microsoft.com/scripting/hey-scripting-guy-how-can-i-sign-windows-powershell-scripts-with-an-enterprise-windows-pki-part-2-of-2/


Can I ask an honest question? Did you read the question or other answers at all? I don't understand why my question has become a dumping ground for everything to do with execution policies. It says very clearly that changing to RemoteSigned is not a solution because that's what it already is! There's already plenty of other answers suggesting this same non-solution.
M
Mo Zaatar

What works for me was right-click on the .ps1 file and then properties. Click the "UNBLOCK" button. Works great fir me after spending hours trying to change the policies.


There are already two answers that ignored what's stated in the question and suggest this same inapplicable solution. I wrote very clearly "I ... used the Sysinternals' streams utility and the file Properties dialog to confirm that the script is not being treated as having come from the Internet" and then "it is both created and executed locally". It even says right in the title that the script is "locally-created". There is nothing to unblock. If unblocking your script solved your problem then you did not have the same problem I had because, as stated, my script was not blocked. -1.
@BACON to be fair, I had the same symptoms as you did and for me unblocking worked. Even thought my script was created locally, I had to unblock it every time after saving it.
This is maybe a work around but not the full correct solution
@SQB Just curious, did you have a roaming profile?
p
pranav aggarwal

Select your terminal Command prompt instead of Power shell. That should work.


What does this even mean? Select it where? The goal was to run a PowerShell script in PowerShell, so using anything other than PowerShell would not work.
I had the same error trying to run AWS Amplify CLI. Running amplify command from WIndows Terminal instead of PowerShell seemed to make it work.
This worked. Not sure it would be considered accepted answer, and I can't say yet why it works but it does.
P
Peter Mortensen

This is an IDE issue. Change the setting in the PowerShell GUI. Go to the Tools tab and select Options, and then Debugging options. Then check the box Turn off requirement for scripts to be signed. Done.


The OP clearly does not want scripts to run unsigned, and did not refer to the IDE.
Not available in Powershell ISE
M
Mustafa Tawfig

Please make a backup for the script.bs1 file

What works for me was deleting the script.bs1 file and running the execution command.


What is the error message you were getting that was solved by doing this?
I have gone through this error 2 different times and fix it the same way. It looks like running the execution command from the CMD will run immediately on the other file with the same name but with the extension (.cmd) .
File C:\Users\UserName\Desktop\Script.ps1 cannot be loaded. The file C:\Users\UserName\Desktop\Script.ps1 is not digitally signed. The script will not execute on the system. ((Script.ps1 not digitally signed error))
I see. And what is returned when you run Get-ExecutionPolicy -List?
MachinePolicy AllSigned, UserPolicy Undefined, Process Undefined, CurrentUser RemoteSigned, LocalMachine Bypass
S
Sumith Ekanayake

This occurs due to Powershell execution policy is set to restricted by default which prevents execution PowerShell scripts and protects from running malicious scripts.

You can change execution scope for specific scope by running the following command

Set-ExecutionPolicy -Scope Process 

It says right in the title of the question that the execution policy in use is RemoteSigned.
P
Peter Mortensen

I was having the same issue and fixed it by changing the default program to open .ps1 files to PowerShell. It was set to Notepad.


You did have this same issue? Or when you'd double-click a .ps1 file it'd open in Notepad instead of executing the script in PowerShell?
P
Pauline

Try running the Powershell GUI as Administrator


As stated in the question, I am both a domain administrator and a local administrator. Running PowerShell elevated would not make a difference as the script was allowed to run unelevated when stored on a network share.
R
Rakesh Dongarwar

Run below 2 commands in PowerShell window

Set-ExecutionPolicy unrestricted Unblock-File -Path D:\PowerShell\Script.ps1


Clearly you did not read the question or the other years-old responses that propose variations of this same inapplicable solution or my comments stating again and again that this is not the answer. I would -10 this if I could, but instead I will have to settle for -1.