{"id":651,"date":"2026-08-18T23:51:19","date_gmt":"2026-08-18T23:51:19","guid":{"rendered":"https:\/\/windows-vps.org\/blog\/?p=651"},"modified":"2026-08-18T23:51:19","modified_gmt":"2026-08-18T23:51:19","slug":"powershell-execution-policy-windows-server-script-signing","status":"publish","type":"post","link":"https:\/\/windows-vps.org\/blog\/powershell-execution-policy-windows-server-script-signing\/","title":{"rendered":"PowerShell Execution Policy on Windows Server: RemoteSigned vs AllSigned vs Unrestricted"},"content":{"rendered":"

“Running scripts is disabled on this system” is the error every new Windows Server admin meets on day one. The cause is the execution policy, and the fix is rarely “set it to Unrestricted.” Execution policy is not a security boundary – a user can bypass it trivially – but it is a useful guardrail that stops accidental script execution and enforces a signing workflow. On an internet-facing VPS, how you configure it matters.<\/p>\n

The policy levels and what they actually do<\/h2>\n
Policy<\/th>Default on<\/th>Behavior<\/th><\/tr><\/thead>
Restricted<\/td>Windows clients<\/td>No scripts run at all; interactive commands only<\/td><\/tr>
RemoteSigned<\/td>Windows Server<\/td>Local scripts run; downloaded scripts must be signed or unblocked<\/td><\/tr>
AllSigned<\/td>–<\/td>Every script must carry a valid signature<\/td><\/tr>
Unrestricted<\/td>–<\/td>All scripts run; downloaded ones prompt once (and are not blocked)<\/td><\/tr>
Bypass<\/td>–<\/td>Nothing is checked; use only for one-off bootstrapping<\/td><\/tr>
Undefined<\/td>–<\/td>No policy set at this scope; falls through to the next scope<\/td><\/tr><\/tbody><\/table><\/figure>\n

RemoteSigned is the sensible default for a server: scripts you write on the box run, and anything that arrived from the internet is blocked until it is signed or explicitly unblocked. The mechanism is the Mark of the Web: files downloaded through a browser carry a Zone.Identifier<\/code> alternate data stream, and RemoteSigned refuses to run scripts that carry it.<\/p>\n

Checking and setting the policy<\/h2>\n
# See every scope and which one wins\nGet-ExecutionPolicy -List\n\n# Set for the machine (needs elevation)\nSet-ExecutionPolicy RemoteSigned -Scope LocalMachine\n\n# One-off bypass for a single command, no permanent change\npowershell -ExecutionPolicy Bypass -File .\\bootstrap.ps1\npwsh -ExecutionPolicy Bypass -File .\\bootstrap.ps1<\/code><\/pre>\n
Scopes are evaluated in a fixed order: MachinePolicy, UserPolicy, Process, CurrentUser, LocalMachine<\/strong>. The first one that is set wins. GPO policies (MachinePolicy<\/code>\/UserPolicy<\/code>) always override everything else, which is how a domain admin pins the setting on managed servers. On a standalone VPS, LocalMachine<\/code> is the scope to use so the policy survives reboots and applies to scheduled tasks and service accounts, not just your interactive session.<\/p>\n
Why you should not reach for Unrestricted<\/h2>\n
Unrestricted on an exposed server means any script that lands on disk – via a dropped web shell, a compromised upload folder, or a phishing-delivered payload – executes without a prompt when invoked. The cost of RemoteSigned is a few seconds of Unblock-File<\/code> when a legitimately downloaded script needs to run:<\/p>\n
# Only for files you have reviewed\nUnblock-File -Path "C:\\tools\\Get-IISLogStats.ps1"\n# or clear the Zone.Identifier stream directly\nRemove-Item "C:\\tools\\Get-IISLogStats.ps1" -Stream Zone.Identifier<\/code><\/pre>\n
Note that curl.exe<\/code> and Invoke-WebRequest<\/code> do not add the Mark of the Web, while browsers and Start-BitsTransfer<\/code> do. A script pulled with curl will run under RemoteSigned even though a browser download of the same file would not – keep that in mind when auditing how files actually arrived.<\/p>\n
Signing scripts for production automation<\/h2>\n
For scheduled tasks and unattended automation, move from “unblock the file” to “sign the script.” Create a code-signing certificate and sign your own scripts:<\/p>\n
New-SelfSignedCertificate -Type CodeSigningCert `\n  -Subject "CN=Ops Scripts (Internal)" `\n  -CertStoreLocation Cert:\\LocalMachine\\My\n\n$cert = Get-ChildItem Cert:\\LocalMachine\\My | Where-Object Subject -like "*Ops Scripts*" | Select-Object -First 1\nSet-AuthenticodeSignature -FilePath "C:\\scripts\\DailyBackup.ps1" -Certificate $cert\n\n# verify\nGet-AuthenticodeSignature "C:\\scripts\\DailyBackup.ps1"<\/code><\/pre>\n
A self-signed certificate keeps the script running under RemoteSigned on the same machine, but other servers will not trust it until you add it to their Trusted Publishers store. For scripts that cross machines, buy a code-signing certificate from a public CA and sign in your build pipeline instead of on the server.<\/p>\n
Execution policy vs. Constrained Language Mode<\/h2>\n
Do not confuse execution policy with language mode. If AppLocker or Windows Defender Application Control (WDAC) policies are active, PowerShell runs in Constrained Language Mode regardless of the execution policy: scripts execute, but they are restricted to a safe subset of the language. On a locked-down VPS, that is the stronger control – execution policy just keeps the careless stuff from running at all.<\/p>\n
A sane baseline for a small Windows VPS<\/h2>\n