Have you ever written a PowerShell script on your local machine, only to be met with frustrating errors when trying to execute it under the RemoteSigned execution policy? You’re not alone. Understanding why your locally-created script is not allowed to run under the RemoteSigned execution policy involves delving into PowerShell’s security features and how it determines the trustworthiness of scripts. This execution policy is designed to protect your system from malicious scripts downloaded from the internet, but it can sometimes feel overly restrictive when dealing with your own creations. We will explore the intricacies of the RemoteSigned execution policy, how it differentiates between local and remote scripts, and provide practical solutions to get your scripts running smoothly and securely.
Understanding the RemoteSigned Execution Policy
The RemoteSigned execution policy is one of PowerShell’s built-in security mechanisms. It dictates the conditions under which PowerShell scripts can execute. Specifically, it states that scripts created on the local computer can run without a digital signature, but scripts downloaded from the internet must be signed by a trusted publisher. This is to prevent unknowingly running potentially harmful scripts that could compromise your system. The core principle is trust: PowerShell needs a way to verify that a script is safe to execute. The RemoteSigned policy trusts scripts you create yourself, assuming you’re not intentionally trying to harm your own system. This trust is implicit for locally created files, bypassing the signature requirement.
However, PowerShell doesn’t always correctly identify a script as “locally created.” The determination is based on the presence of an Alternate Data Stream (ADS) named “Zone.Identifier.” When you download a file from the internet, Windows automatically adds this stream, tagging the file as originating from an external source. This tag prompts PowerShell to check for a valid digital signature when the RemoteSigned policy is in effect. Even if you copy a script from a network share or an email attachment to your local machine, it may still carry this “Zone.Identifier” stream, causing it to be treated as a remote script, and therefore subject to the signature requirement. This is a common source of confusion.
In essence, the RemoteSigned policy aims to strike a balance between security and usability. It allows developers and system administrators to run their own scripts without the burden of signing them while still providing a layer of protection against potentially malicious code. However, its reliance on the “Zone.Identifier” stream can sometimes lead to unexpected behavior, requiring users to understand how to bypass these checks when necessary. Learning to manage execution policies is a crucial skill for anyone working with PowerShell. For more detailed information, you can refer to the official Microsoft documentation on about_Execution_Policies [^1^].
Why Locally Created Scripts Sometimes Fail
The seemingly contradictory behavior of RemoteSigned – allowing local scripts but blocking some – stems from how Windows and PowerShell handle file origins. As mentioned, the “Zone.Identifier” ADS plays a critical role. When a file is downloaded from the internet or received as an email attachment, Windows attaches this stream, essentially marking the file as originating from an untrusted source. This stream persists even if you copy the file to your local hard drive. This is a common reason why your locally-created script is not allowed to run under the RemoteSigned execution policy, even if technically the file now resides on your local machine.
Another factor is the method used to create the script. If you create the script using a text editor that automatically downloads updates or templates from the internet, the resulting file might inadvertently inherit the “Zone.Identifier” stream. Similarly, if you copy and paste code from a website directly into a script file, the “Zone.Identifier” stream associated with the browser might be transferred along with the code. This “contamination” can lead to PowerShell treating the script as a remote file, even if you manually created the file on your local system.
Furthermore, certain file sharing protocols or cloud storage services can also introduce the “Zone.Identifier” stream. For example, if you download a script from a shared folder on OneDrive or Dropbox, the file might be tagged as originating from the internet. Therefore, it’s important to be aware of the source of your scripts and the potential impact of file transfer methods on PowerShell’s execution policy. The key takeaway is that PowerShell doesn’t solely rely on the physical location of the file but also considers its origin based on the presence of the “Zone.Identifier” stream.
Solutions to Run Your Locally-Created Scripts
Fortunately, there are several ways to resolve the issue of your locally-created script being not allowed to run under the RemoteSigned execution policy. One of the simplest methods is to unblock the file. To do this, right-click on the script file in File Explorer, select “Properties,” and check the “Unblock” box at the bottom of the “General” tab. This removes the “Zone.Identifier” stream, effectively telling PowerShell that the script is safe to run. This is often the quickest and easiest solution for individual scripts. The following paragraph is optimized as a featured snippet:
The easiest way to solve the RemoteSigned issue is to unblock the script. Right-click the .ps1 file in File Explorer, go to Properties, and look for a checkbox labeled “Unblock” near the bottom. Check the box, click Apply, and then OK. This removes the Zone.Identifier, effectively telling PowerShell that you trust the script and it’s safe to run.
Another approach is to modify the execution policy for your user account or the entire system. However, this should be done with caution, as it can weaken your system’s security. To change the execution policy, open PowerShell as an administrator and use the Set-ExecutionPolicy cmdlet. For example, Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope CurrentUser will bypass the execution policy for your current user account. It is generally recommended to avoid setting the execution policy to Unrestricted, as this disables all security checks. You could also consider signing your own scripts using a code signing certificate. This involves obtaining a certificate from a trusted Certificate Authority (CA) or creating your own self-signed certificate. While self-signed certificates are free, they are not trusted by default, so you’ll need to import the certificate into the Trusted Root Certification Authorities store on your system. Detailed instructions can be found at [^2^] DigiCert’s Code Signing guide.
Here’s an ordered list demonstrating the steps for unblocking a file:
- Locate the PowerShell script in File Explorer.
- Right-click on the script file.
- Select “Properties” from the context menu.
- In the “General” tab, look for a section labeled “Security” at the bottom.
- If present, check the “Unblock” box.
- Click “Apply” and then “OK”.
Best Practices for Script Execution and Security
While it’s important to be able to run your scripts, it’s equally crucial to maintain a strong security posture. Modifying the execution policy should always be a last resort, and you should carefully consider the potential risks before doing so. A better approach is to adopt secure coding practices and to sign your scripts, especially if you intend to share them with others. Code signing provides assurance that the script has not been tampered with since it was signed, and it allows recipients to verify the identity of the author.
Regularly review your scripts for potential security vulnerabilities. Be wary of hardcoding credentials or sensitive information directly into your scripts. Instead, use secure configuration files or environment variables to store such data. Also, ensure that your scripts properly handle user input to prevent injection attacks. When downloading scripts from the internet, always verify the source and carefully examine the code before running it. Avoid running scripts from untrusted sources, and be particularly cautious of scripts that request elevated privileges.
Here are some key points to remember:
- Always verify the source of your scripts before running them.
- Use code signing to ensure the integrity of your scripts.
- Regularly review your scripts for security vulnerabilities.
Here are some additional security measures to consider:
- Implement a robust password policy for your system.
- Keep your operating system and software up to date.
- Use a reputable antivirus program.
FAQ: RemoteSigned and Script Execution
- Why can't I run a script I created myself?
- Even if you created the script, it might have a "Zone.Identifier" stream indicating it came from the internet. Unblocking the file typically resolves this.
- Is it safe to change the execution policy to "Unrestricted"?
- No, setting the execution policy to "Unrestricted" disables all security checks and is highly discouraged.
- What is code signing?
- Code signing involves digitally signing your scripts with a certificate to prove their authenticity and integrity.
- How do I unblock a script?
- Right-click the file, select "Properties," and check the "Unblock" box.
So, the next time you encounter the “locally-created script is not allowed to run under the RemoteSigned execution policy” error, you’ll be equipped with the knowledge and tools to resolve it quickly and confidently. Remember to always prioritize security and adopt best practices for script execution. Don’t let security stand in the way of progress – embrace it as a necessary component of responsible scripting. Now, go forth and create powerful, secure PowerShell scripts! Need to learn more about script signing? Check out our other articles about advanced PowerShell security techniques.
[^1^]: Microsoft Documentation: [https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_execution_policies?view=powershell-7.3](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_execution_policies?view=powershell-7.3) [^2^]: DigiCert Code Signing Guide: [https://www.digicert.com/signing/code-signing](https://www.digicert.com/signing/code-signing) [^3^]: Microsoft PowerShell Security: [https://devblogs.microsoft.com/powershell/powershell-security-considerations/](https://devblogs.microsoft.com/powershell/powershell-security-considerations/) Question & Answer :
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
RemoteSignedexecution policy is preventing script execution when it shouldn’t.RemoteSignedis 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 fromRemoteSignedtoRemoteSignedis 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?
Some things to check:
Can you change to unrestricted?
Set-ExecutionPolicy Unrestricted
Is the group policy set?
Computer Configuration\Administrative Templates\Windows Components\Windows PowerShellUser 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
