Execute PowerShell script from PowerShell is the procedure of running a .ps1 file from a PowerShell session or from cmd.exe using the call operator (&), dot-sourcing (.), or the -File parameter. Requires appropriate execution policy.
# From within PowerShell — call operator (recommended)
& "C:PathScript.ps1" [-Param1 Value1] [-Param2]
Tested on Windows 11 22H2 with PowerShell 7.6 and Windows PowerShell 5.1.
Syntax
# From within PowerShell — call operator (recommended)
& "C:PathScript.ps1" [-Param1 Value1] [-Param2]
# From within PowerShell — dot-sourcing (runs in current scope)
. "C:PathScript.ps1"
# From cmd.exe or Run dialog
powershell.exe -ExecutionPolicy Bypass -File "C:PathScript.ps1" [-Param1 Value1]
# From cmd.exe — with -NoExit to keep console open
powershell.exe -NoExit -File "C:PathScript.ps1"
# From PowerShell — using the call operator with inline arguments
& "C:PathScript.ps1" -Server HQ -Port 8080
Options and Flags
| Flag / Syntax | Type | Default | Description |
|---|---|---|---|
-ExecutionPolicy Bypass |
String | Restricted (Windows) | Temporarily bypasses script execution restriction for this session. Does not modify system policy. |
-File <Path> |
String | N/A | Specifies the .ps1 script to execute. All subsequent arguments are passed to the script as literal strings. |
-NoExit |
Switch | False | Keeps the PowerShell console open after script completes. Useful for debugging or inspecting output. |
& (call operator) |
Operator | N/A | Executes a command or script in a child scope. Required when path contains spaces or variables. |
. (dot-source) |
Operator | N/A | Executes a script in the current scope. Variables and functions defined persist after completion. |
-Command |
String | N/A | Executes a command string. Use & "C:PathScript.ps1" inside the string. Prefer -File for scripts. |
-WindowStyle Hidden |
String | Normal | Launches PowerShell with a hidden window. Used in scheduled tasks and silent automation. |
Usage Examples
Example 1: Run a script from the current directory
# Navigate to the script location and execute
cd "C:Deploy"
.DeployApp.ps1 -Environment Production -Version 3.2.1
If the path contains no spaces, .DeployApp.ps1 executes the script in a child scope. The -Environment and -Version parameters are passed as named arguments. All script-scope variables are discarded after completion.
Example 2: Invoke a script from cmd.exe with bypass policy
powershell.exe -ExecutionPolicy Bypass -File "C:ScriptsHealthCheck.ps1" -Server "DB-01"
This is the standard pattern for running PowerShell scripts from batch files, scheduled tasks, or CI/CD agents. The -ExecutionPolicy Bypass flag overrides the default Restricted policy for that single invocation — no permanent change is made to the registry or GP.
Example 3: Dot-source a utility script to load functions
# Load all functions from a shared lib into the current session
. "C:LibCommonFunctions.ps1"
# Now call functions defined in the script
Get-ServerStatus -Name "WEB-01"
Invoke-LogCleanup -RetentionDays 30
Dot-sourcing runs the script in the caller’s scope. Any functions, aliases, or variables defined in CommonFunctions.ps1 persist in the session. Use this pattern for shared libraries — but avoid it for deployment scripts where scope isolation is desirable.
Example 4: Run with explicit exit code capture
# From PowerShell
& "C:ScriptsBackup.ps1"
$exitCode = $LASTEXITCODE
Write-Host "Script exited with code $exitCode"
# From cmd.exe
powershell.exe -File "C:ScriptsBackup.ps1"
echo %ERRORLEVEL%
PowerShell maps the script’s exit statement to $LASTEXITCODE. The cmd ERRORLEVEL variable captures the same value. Always capture exit codes in automation to detect failures.
Troubleshooting & Common Errors
| Error Message / Code | Root Cause | Resolution Command |
|---|---|---|
File cannot be loaded because running scripts is disabled on this system |
Execution policy is Restricted (Windows default). |
powershell.exe -ExecutionPolicy Bypass -File "script.ps1" |
'.' is not recognized as an internal or external command |
Ran .script.ps1 from cmd.exe, not from PowerShell. |
Use powershell.exe -File "script.ps1" instead of .script.ps1. |
The term 'script.ps1' is not recognized |
Script not found in PATH or current directory; spaces in path without &. |
& "C:My Scriptsscript.ps1" |
| Exit code 255 | PowerShell.exe could not parse or locate the script. | Verify absolute path. Use -File not -Command for scripts.
|
Access to the path is denied |
File system permissions; script not readable. | Check ACLs: icacls "C:Pathscript.ps1". Ensure the executing user has Read permission. |
Closing Tip
Always run PowerShell scripts from automation with -ExecutionPolicy Bypass -File and capture $LASTEXITCODE immediately, because no other single pattern consistently handles spaces, permissions, and exit-code propagation across both Windows PowerShell 5.1 and PowerShell 7.x.
Multi-Cloud Comparison
PowerShell script execution is a local OS operation. No cloud provider exposes a native subcommand to run a .ps1 file. The following table maps equivalent concepts for remote execution on cloud VMs.
| Feature | Local PowerShell | AWS (EC2 / Systems Manager) | Azure (VM / Run Command) |
|---|---|---|---|
| Run .ps1 on VM | .script.ps1 |
aws ssm send-command --document-name "AWS-RunPowerShellScript" --parameters commands=["powershell -File script.ps1"] |
az vm run-command invoke --command-id RunPowerShellScript --scripts "powershell -File script.ps1" |
| Execution policy override | -ExecutionPolicy Bypass |
Configure per-instance via Group Policy or ssm agent | Configure per-instance via Azure Policy or custom script extension |
| Persist script output | Redirect > output.log |
--output-s3-bucket-name (SSM) |
Output returned in command response; can write to blob storage |
| Pass arguments | .script.ps1 -Arg1 Value1 |
--parameters "args"=["Value1"] |
--parameters "arg1=Value1" |
Frequently Asked Questions
What is the difference between dot-sourcing (.) and the call operator (&) when executing a PowerShell script?
Answer: Dot-sourcing (.) runs the script in the current scope, while the call operator (&) runs it in a child scope.
Use . .script.ps1 when you want to persist script-defined functions or variables into the current session. Use & .script.ps1 to prevent scope pollution. The call operator also allows invoking a script by path stored in a variable: & $scriptPath.
When should I use the -ExecutionPolicy flag when executing a script?
Answer: Use -ExecutionPolicy Bypass when running a script from a non-trusted source or in automation to immediately override restrictive policies.
Example:
powershell.exe -ExecutionPolicy Bypass -File C:deployscript.ps1
This flag is valid for both powershell.exe and pwsh.exe. For scripts launched from within another PowerShell session, set the policy for the child process: Start-Process powershell.exe -ArgumentList '-ExecutionPolicy RemoteSigned -File .script.ps1'.
How do I fix ‘File cannot be loaded because running scripts is disabled on this system’ (error code: System.UnauthorizedAccessException)?
Answer: Set the execution policy to RemoteSigned or Bypass: Set-ExecutionPolicy -Scope CurrentUser RemoteSigned.
Run from an elevated PowerShell window:
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine -Force
For a one-shot bypass without changing policy, launch the script with powershell.exe -ExecutionPolicy Bypass -File script.ps1. If Group Policy enforces the restriction, use Bypass at invocation or run powershell.exe -ExecutionPolicy Unrestricted for the session.
Does executing PowerShell scripts work on Linux and macOS with PowerShell Core?
Answer: Yes, PowerShell Core (pwsh) runs scripts cross‑platform.
On Linux/macOS, ensure the script has execute permissions (chmod +x script.ps1) and includes a shebang: #!/usr/bin/env pwsh. Execution policy is less restrictive on non‑Windows systems; however, Set-ExecutionPolicy is only supported on Windows. Use pwsh -File script.ps1 directly. For CI/CD pipelines, always specify the full path to the script.
What is the fastest way to execute a PowerShell script from PowerShell with minimal overhead?
Answer: Use the call operator with a direct path: & 'C:pathtoscript.ps1'.
For in‑process execution (no child process), call the script directly by its path. To bypass execution policy without spawning a new process, set policy once per session or use Set-ExecutionPolicy Bypass -Scope Process -Force. Avoid piping to Invoke-Expression (IEX) for performance. For parallel execution of many scripts, use $jobs = 1..10 | ForEach-Object { Start-Job -ScriptBlock { & "C:scriptsjob$_.ps1" } }.

Command Line Expert & Software Engineer
Welcome! I’m Thomas Heinrich, a software engineer and system administrator with a deep passion for the Command Line Interface (CLI). With years of experience navigating the terminal, building backend architectures, and automating server deployments, I created this space to share practical, real-world terminal knowledge.
Whether you are a beginner taking your first steps in a Linux environment or a seasoned DevOps engineer looking to optimize your deployment scripts, you will find actionable solutions here. My goal is to help you ditch the mouse, speed up your workflow, and harness the full power of the command line.