PowerShell scripts fail to run after updating to version 7 on Windows 10 primarily because the execution policy resets or conflicts with system security settings. This issue often stems from the new installation path not inheriting previous configurations, leaving scripts blocked by default policies. You can resolve this by explicitly setting the execution policy for the current user and verifying that your script files are not blocked by Windows Defender.
Understanding Execution Policy Changes
When you install PowerShell 7 (pwsh), it operates as a separate instance from the legacy Windows PowerShell 5.1. Unlike its predecessor, the newer version does not automatically inherit the execution policy settings configured in the registry for Windows PowerShell. By default, PowerShell 7 sets the execution policy to Restricted, which prevents any scripts from running unless they are digitally signed or you change the policy. This is a deliberate security measure to protect users who may be unaware of the risks associated with running unsigned code.
To check your current execution policy, open PowerShell 7 and run the following command:
Get-ExecutionPolicy -List
This command displays the execution policy for each scope: Local Machine, Current User, and Process. If the Current User or Process scopes show Restricted, your scripts will fail to execute even if the Local Machine policy allows them. The most effective solution is to set the policy for the Current User, which requires no administrative privileges and applies only to your account.
Setting the Correct Execution Policy
To allow scripts to run, you need to change the execution policy to RemoteSigned or Unrestricted. RemoteSigned is generally recommended for most users because it allows locally created scripts to run while requiring downloaded scripts to be signed by a trusted publisher. To apply this change, use the Set-ExecutionPolicy cmdlet with the Scope parameter specified as CurrentUser.
Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned
You will be prompted to confirm the change; type Y and press Enter. After executing this command, try running your script again using the full path to the file. For example, if your script is located at C:\Scripts\MyScript.ps1, you would run .\C:\Scripts\MyScript.ps1. If the script runs successfully, the issue was indeed related to the execution policy. Note that this change persists across sessions but only affects your specific user profile.
If you encounter permission errors when trying to set the policy, ensure that you are running PowerShell 7 as the correct user. Sometimes, residual settings from previous installations can interfere. In such cases, restarting the PowerShell session or logging out and back in can clear temporary state issues. Additionally, verify that no group policies are overriding your local settings, especially if you are on a corporate network. For more insights on handling persistent script issues, consider reviewing our guide on
PowerShell Script Not Working: Remove First 9 Characters of Certain Files.
Checking File Attributes and Security Blocks
Even with the correct execution policy, scripts may still fail to run if Windows marks the file as blocked. When you download a script from the internet, Windows adds an alternate data stream called Zone.Identifier to the file, indicating its origin. PowerShell respects this attribute and blocks execution to prevent potential malware. To remove this block, right-click the script file in File Explorer, select Properties, and look for a checkbox labeled "Always ask before opening this file" or a message stating "This file came from another computer and might be blocked." Click the Unblock button next to it and apply the changes.
For bulk unblocking, you can use the Unblock-File cmdlet in PowerShell. This is particularly useful if you have multiple scripts in a directory that need to be executed. Run the following command to unblock all PowerShell files in the current directory:
Get-ChildItem -Filter *.ps1 | Unblock-File
This command retrieves all files with the .ps1 extension and pipes them to Unblock-File, which removes the Zone.Identifier stream. After unblocking, attempt to run the script again. If it still fails, check the error message carefully. Common errors include missing dependencies or syntax issues introduced during the update process. Ensure that your script does not rely on modules that were removed or updated in the new PowerShell version.
Verifying Module Compatibility
After updating to PowerShell 7, some modules may become incompatible due to changes in the underlying framework. PowerShell 7 uses .NET Core, whereas Windows PowerShell 5.1 uses the full .NET Framework. Modules designed for .NET Framework may not work correctly in PowerShell 7. To identify problematic modules, check the error logs for references to missing types or assemblies. You can also list installed modules using Get-Module -ListAvailable and compare them against your requirements.
If a specific module is causing issues, consider installing a compatible version or using a workaround. Some popular modules have been updated to support PowerShell 7, so check for updates via the PowerShell Gallery. Use the Update-Module cmdlet to fetch the latest versions. If no update is available, you may need to contact the module author or find an alternative solution. For troubleshooting deeper integration issues, such as those involving third-party shells, see our article on
PowerShell Not Starting in ConEmu on Windows 10: A Troubleshooting Guide.
Reinstalling PowerShell 7
If none of the above steps resolve the issue, a clean reinstall of PowerShell 7 might be necessary. Corrupted installation files or conflicting registry entries can cause unexpected behavior. Before reinstalling, uninstall the current version via Settings > Apps > Installed Apps. Then, download the latest installer from the official GitHub repository. During installation, ensure that you select the option to add PowerShell to the PATH environment variable if you prefer launching it from the command line.
After reinstallation, repeat the steps to set the execution policy and unblock your scripts. This fresh start often clears up lingering configuration problems. Keep in mind that custom configurations, aliases, and profiles will need to be recreated. Back up your profile files located in $PROFILE before uninstalling to preserve your settings. If you continue to experience difficulties, consider checking Windows Event Viewer for detailed error logs related to PowerShell crashes or failures.
Frequently Asked Questions
Why did my scripts stop working immediately after the update?
The update likely reset the execution policy to Restricted for PowerShell 7, which does not inherit settings from Windows PowerShell 5.1. You must manually set the policy to RemoteSigned or Unrestricted for your user account to allow script execution again.
Can I set the execution policy globally for all users?
Yes, you can use the Scope parameter set to LocalMachine with administrative privileges. However, this is generally discouraged for individual desktops due to security risks, as it allows any script to run without restriction across the entire system.
What does the Unblock-File cmdlet actually do?
Unblock-File removes the Zone.Identifier alternate data stream from files, which Windows uses to mark downloads from the internet as potentially unsafe. Removing this stream tells PowerShell that the file is safe to execute based on your current execution policy.
Will changing the execution policy affect other applications?
No, the execution policy only affects how PowerShell interprets and runs script files. It has no impact on other applications, system stability, or general Windows functionality. It is a sandboxed security feature specific to the PowerShell engine.
How do I restore my old PowerShell profile after reinstalling?
You can copy your saved $PROFILE file from the backup location to the new installation directory. The profile path remains the same ($HOME\Documents\PowerShell\Microsoft.PowerShell_profile.ps1) unless you have customized it, ensuring your aliases and functions are restored.