Find the Effective PowerShell Execution Policy Before Changing It Again
A successful settings command can change one scope while another scope continues to determine what PowerShell allows. Establish the effective policy in the window where the script fails, rather than repeatedly applying broader changes.
Record the script's source, exact error, PowerShell version and whether this is a managed work computer. Read unfamiliar script contents before considering execution. This diagnostic task does not require running the blocked script.
Read both the result and the scope list
In the affected PowerShell session on Windows, run these read-only commands:
Get-ExecutionPolicy
Get-ExecutionPolicy -List
The first returns the effective policy. The second shows configured policies by scope. Microsoft explains that Group Policy settings, MachinePolicy and UserPolicy, take precedence over settings chosen in PowerShell.
Without a controlling Group Policy, Process takes precedence over CurrentUser, which takes precedence over LocalMachine. A process-scoped setting lasts only for that session and its children. A user-level setting can therefore explain why a machine-level change did not alter the effective result.
Preserve both outputs together. One isolated LocalMachine value is not a complete description of the session's policy.
Match the message to the actual restriction
Restricted allows individual commands but prevents scripts. RemoteSigned has a different rule for downloaded scripts, requiring a trusted signature unless the file has been deliberately unblocked. A policy that permits some scripts is not a promise that every downloaded file will run.
Microsoft describes execution policy as a safety feature rather than a security boundary. Do not treat successful execution as evidence that a script is trustworthy, or use a blanket bypass setting to avoid understanding a blocked download.
If organisational policy controls the result, give the administrator the scope list and exact message. If you administer the PC, decide the narrow intended policy only after confirming the script and requirement; then verify the effective result in the relevant session.
Keep a record of any separately approved change and its scope. A different tab, user account or PowerShell installation should be checked in its own context instead of inheriting an assumption from this one observation.