How to Run PowerShell Scripts from .ps1 Files: Solving Execution Policy and Automation Issues

Problem Background and Phenomenon Analysis

In Windows automation tasks, PowerShell scripts are widely used due to their powerful capabilities. However, many users encounter a typical issue: scripts run well in interactive PowerShell environments but fail to work when saved as .ps1 files and executed via double-clicking or remotely. Taking the user-provided code as an example, the script aims to open an Excel file, read content from a specific cell, and delete the corresponding text file. When code is entered directly in the Shell, the operation succeeds; but when saved as a .ps1 file and executed, only a window pops up with no actual effect.

The root cause of this phenomenon lies in PowerShell's Execution Policy. By default, Windows systems restrict the execution of unsigned scripts for security reasons, to prevent malicious code from running. When users double-click a .ps1 file, the system may start PowerShell in a restricted mode, causing the script to be blocked. In contrast, interactive Shells are usually configured to allow execution of user-entered code, thus avoiding this issue.

Core Solution: Using Batch Files for Invocation

According to the best answer (Answer 1), the most effective solution is to create a batch file (.bat) that explicitly calls the .ps1 script via PowerShell.exe, specifying execution policy parameters. For example, create a batch file with the following content:

Powershell.exe -executionpolicy remotesigned -File "C:\Path\script.ps1"

Here, the -executionpolicy remotesigned parameter allows running locally created scripts, while remote scripts still require signing, striking a balance between security and convenience. If the script path contains spaces, it must be wrapped in quotes, as shown in the example. Additionally, if the operation requires administrator privileges (e.g., deleting system files), right-click the batch file and select "Run as administrator".

To further verify the execution process, it is recommended to manually run the batch file in Command Prompt (CMD) and observe the output. For example, in CMD, enter: "C:\Path\batchfile.bat", which helps diagnose permission or path errors.

Supplementary Methods: Direct Execution and Policy Adjustment

Other answers (e.g., Answer 2) provide alternative approaches. The simplest way is to right-click the .ps1 file and select "Run with PowerShell", but this may still be affected by execution policies. Another method is to directly use powershell.exe -File C:\Script.ps1 in Command Prompt or a batch file. If policy restrictions are encountered, add the -ExecutionPolicy Bypass parameter to bypass all restrictions, e.g., powershell.exe -File C:\Script.ps1 -ExecutionPolicy Bypass. However, note that this reduces security and is only recommended in controlled environments.

For long-term solutions, the execution policy can be permanently changed. Run Set-ExecutionPolicy RemoteSigned in PowerShell, which will allow local script execution. However, in enterprise environments, this may be restricted by group policies and require administrator privileges.

Code Example and In-Depth Analysis

Using the user-provided script as an example, we rewrite and explain its core logic:

$Excel = New-Object -ComObject Excel.Application
$Workbook = $Excel.Workbooks.Open('H:\codes\test1.xlsm')
$workSheet = $Workbook.Sheets.Item(2)
$str_name = $workSheet.Cells.Item(2,1).Text
Remove-Item -Path "H:\text files\$str_name.txt" -Force

This code first creates an Excel application object, opens the specified workbook, accesses the second worksheet, reads the text value from the second row and first column, then forcibly deletes the text file at the corresponding path. In automated execution, ensuring correct file paths and that PowerShell has sufficient permissions to access these resources is key. For example, if the path includes a network drive (e.g., H:), mapping or using full UNC paths may be necessary in batch execution.

Best Practices and Conclusion

To reliably run PowerShell scripts, it is recommended to follow these steps: first, test the script's functionality in an interactive Shell; second, create a batch file that calls the script using the -executionpolicy remotesigned parameter; finally, adjust execution policies or use administrator privileges as needed. Avoid double-clicking .ps1 files directly, as this relies on system default settings, which may be inconsistent.

In summary, execution issues with PowerShell scripts often stem from security policy restrictions. By understanding the execution policy mechanism and adopting encapsulation methods like batch files, script automation can be easily achieved while maintaining system security. For complex tasks, consider adding error handling and logging to enhance script robustness.