Calling PowerShell from Batch

Batch files and PowerShell are not mutually exclusive; a very common real-world pattern is a thin .bat wrapper that handles simple orchestration (checking for admin rights, setting environment variables, being double-clickable without an execution-policy prompt) while delegating any task requiring structured data, .NET objects, or modern cmdlets to an embedded PowerShell call. This lets teams keep a familiar batch entry point, useful for legacy deployment tooling or login scripts, while still leveraging PowerShell's richer capabilities such as Get-Service, Invoke-WebRequest, or Active Directory cmdlets for the parts of the job batch simply cannot do well.

From a batch file, powershell.exe -NoProfile -Command "Get-Service -Name Spooler | Select-Object Status" runs an inline command, while powershell.exe -NoProfile -ExecutionPolicy Bypass -File "C:\Scripts\Deploy.ps1" runs a full .ps1 script file. -NoProfile skips loading the user's PowerShell profile for faster, more predictable startup in automation contexts, and -ExecutionPolicy Bypass overrides the machine's default script-execution restriction for that single invocation only, without permanently changing the system policy. On modern Windows, pwsh.exe (PowerShell 7+) can be called instead of the legacy powershell.exe (Windows PowerShell 5.1) if the cross-platform, actively developed version is installed and required.

Batch variables are passed to a PowerShell script as ordinary command-line parameters after -File, matched against a param() block defined at the top of the .ps1 file, e.g. param([string]$Environment, [string]$Version). To capture PowerShell's output back into batch, wrap the invocation in a for /f loop using backticks, which reads each line of stdout into a loop variable, exactly as you would capture output from any other console command. For exit-code propagation, a PowerShell script should call exit with an explicit integer (exit 1 on failure), which then surfaces to the batch caller as the normal %errorlevel%, since PowerShell's own $LASTEXITCODE only matters within PowerShell itself and must be explicitly turned into a process exit code to be visible to cmd.exe.

PowerShell's execution policy (Restricted, AllSigned, RemoteSigned, Unrestricted) is a safety rail, not a security boundary; it exists to prevent accidental execution of scripts, not to stop a determined attacker, since it can always be overridden per-invocation with -ExecutionPolicy Bypass as shown above, or bypassed entirely by piping script content directly into powershell -Command. Because -ExecutionPolicy Bypass is so commonly used in legitimate automation, it is also a well-known pattern abused by malicious batch files that download and execute a remote payload with a single line, so security teams and antivirus/EDR products specifically watch for the combination of powershell.exe with -enc (encoded command), -windowstyle hidden, and Bypass appearing together.