PowerShell Script Execution Error: Complete Fix Guide

The issue you’re experiencing is a common problem with PowerShell execution policies on 64-bit Windows systems. The error occurs because Windows runs both 32-bit (x86) and 64-bit versions of PowerShell, and each has its own separate execution policy setting.

When you run powershell.exe from cmd.exe without specifying the architecture, it defaults to the 32-bit version, which still has its original restrictive execution policy despite your changes to the 64-bit version.

Contents

• Understanding the Architecture Issue
• Checking Execution Policies for Both Architectures
• Solution: Run 64-bit PowerShell from cmd.exe
• Alternative: Set Execution Policy for Both Architectures
• Additional Troubleshooting Steps
• Best Practices for PowerShell Script Execution

Understanding the Architecture Issue

On 64-bit Windows systems, PowerShell exists in two separate versions:

• 64-bit PowerShell: %SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe
• 32-bit PowerShell: %SystemRoot%\SysWOW64\WindowsPowerShell\v1.0\powershell.exe

When you run powershell.exe from cmd.exe, it typically launches the 32-bit version (x86) due to Windows File System Redirector behavior. The warning message “WARNING: Running x86 PowerShell…” confirms this is what’s happening in your case.

Each version maintains its own execution policy independently, so setting it in one doesn’t affect the other.

Checking Execution Policies for Both Architectures

To verify this, check the execution policy for both architectures:

# For 32-bit PowerShell (what's running from cmd.exe by default)
%SystemRoot%\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -Command "Get-ExecutionPolicy"

# For 64-bit PowerShell (what you likely configured)
%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe -Command "Get-ExecutionPolicy"

You’ll likely see that the 32-bit version still has a restrictive policy like Restricted or RemoteSigned, while the 64-bit version shows Unrestricted.

Solution: Run 64-bit PowerShell from cmd.exe

The quickest fix is to explicitly run the 64-bit version of PowerShell from cmd.exe:

cd "C:\Projects\Microsoft.Practices.ESB\Source\Samples\Management Portal\Install\Scripts"
%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe -File .\Management_Install.ps1 1

Alternatively, you can use the -ExecutionPolicy parameter to override the current policy:

powershell.exe -ExecutionPolicy Unrestricted -File .\Management_Install.ps1 1

However, the first method is more reliable as it ensures you’re using the correct architecture.

Alternative: Set Execution Policy for Both Architectures

If you want both versions to have the same policy, set it for both architectures:

# Set for 64-bit PowerShell
%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe -Command "Set-ExecutionPolicy Unrestricted -Force"

# Set for 32-bit PowerShell  
%SystemRoot%\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -Command "Set-ExecutionPolicy Unrestricted -Force"

The -Force parameter prevents confirmation prompts.

Additional Troubleshooting Steps

If the above solutions don’t work, consider these additional factors:

1. User Account Control (UAC) Issues

On Windows Server 2008 R2, UAC might interfere with script execution. Try running cmd.exe as an administrator first, then execute your PowerShell command.

2. System-Wide Group Policy

Check if there’s a system-wide Group Policy that overrides your user-level setting:

• Open gpedit.msc
• Navigate to Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell
• Verify that “Turn on Script Execution” is not set to “Disabled”

3. Script Signing Requirements

Even with Unrestricted policy, if the script requires signing (which shouldn’t be the case with Unrestricted), you might need to bypass signing checks:

powershell.exe -ExecutionPolicy Bypass -File .\Management_Install.ps1 1

4. Script Content Issues

Verify that your script doesn’t contain syntax errors or cmdlets that are restricted by other security mechanisms beyond execution policy.

Best Practices for PowerShell Script Execution

To avoid similar issues in the future:

1. Always specify the PowerShell architecture when running scripts from cmd.exe:

   cmd

   # For 64-bit scripts
   %SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe -File script.ps1
   
   # For 32-bit scripts (rare)
   %SystemRoot%\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -File script.ps1
   

2. Use the -ExecutionPolicy parameter when running scripts to ensure consistent behavior:

   cmd

   powershell.exe -ExecutionPolicy Unrestricted -File script.ps1
   

3. Set execution policies consistently across both architectures when deploying scripts to multiple systems.

4. Consider using PowerShell ISE or Visual Studio Code for script development and testing, as these tools provide better error feedback.

5. Document script requirements including the required PowerShell version and execution policy to avoid deployment issues.

By explicitly running the 64-bit version of PowerShell from cmd.exe, you should be able to execute your script successfully despite the execution policy mismatch between architectures.