powershellpowershell-2.0code-signingexecutionpolicy

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...

Solution

  • 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):

    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.