• Login
  • Register

Community Dashboard

Our community dashboard tracks activity and engagement from community members across a wide variety of sources, including, the DNN forum, Twitter, GitHub, StackOverflow, etc.
PrevPrev Go to previous topic
NextNext Go to next topic
Last Post 01 Feb 2022 11:45 AM by  Mawadda Abuhamda
Why the RemoteSigned policy is preventing script execution in PowerShell
 0 Replies
You are not authorized to post a reply.
Author Messages

New Member

New Member

01 Feb 2022 11:45 AM
    Something that might help with script execution in PowerShell if the RemoteSigned policy is preventing execution, is to change the policy from RemoteSigned to Unrestricted. You can use “Set-ExecutionPolicy Unrestricted” to change the policy.
    You can also try to bypass the policy using “powershell.exe -executionpolicy bypass -file .\Script.ps1.”
    You can also add a URL rule to the Intranet group to trust the directory that the file is on. You can do this by running the command, “& "$Env:SystemRoot\Microsoft.NET\Framework64\v2.0.50727\caspol.exe" -machine -listgroups.” Then you need to delete the group called 1.2.3. by running the command, “& "$Env:SystemRoot\Microsoft.NET\Framework64\v2.0.50727\caspol.exe" -machine -remgroup 1.2.3.”

    Article from: https://stackoverflow.com...e-remotesigned-execu

    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

    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)
    Removed code group from the Machine level.
    ...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.
    You are not authorized to post a reply.