Sådan løser du Execution Policy Restricted-fejlen i Windows PowerShell

Den sikreste måde at løse en “Execution Policy Restricted”-fejl i Windows PowerShell på er ikke at kopiere den bredeste kommando, du kan finde. Identificér først, hvilken execution policy der faktisk er aktiv, og vælg derefter den mest begrænsede ændring, der passer til det, du forsøger at køre.

Microsofts aktuelle dokumentation understreger også vigtigheden af versionskontekst. Dokumentationen for Windows PowerShell 5.1 angiver Restricted som standard execution policy for Windows-klientcomputere. Den aktuelle dokumentation for PowerShell 7.6 definerer Default som RemoteSigned på Windows. Hvis alle områder er Undefined, dokumenterer Microsoft dog stadig, at den effektive fallback på Windows-klienter er Restricted. Den praktiske læring er enkel: udled ikke din politik ud fra din Windows-version eller fra en vejledning. Kør politikkommandoerne på den maskine, der har fejlen.

Denne guide sammenligner de vigtigste løsninger efter omfang, vedvarende effekt, administrativ påvirkning og tillidsmodel. Målet er at få en legitim scriptfil til at køre uden at svække mere af systemet end nødvendigt.

Hvad Restricted-fejlen faktisk betyder

Under Restricted-politikken tillader PowerShell individuelle kommandoer, men tillader ikke, at scriptfiler køres. Det omfatter PowerShell-scripts og relaterede konfigurations- eller modulscriptfiler. Microsoft beskriver execution policy som en sikkerhedsfunktion, der styrer betingelserne for, hvornår scripts og konfigurationsfiler indlæses. Det er ikke en sikkerhedsgrænse; Microsoft bemærker eksplicit, at en bruger stadig kan indtaste kommandoer interaktivt. Læs den aktuelle about_Execution_Policies-dokumentation for PowerShell 7.6 og Windows PowerShell 5.1 execution policy-dokumentation.

Den almindelige fejl angiver, at .ps1-filen ikke kan indlæses, fordi kørsel af scripts er deaktiveret; tag en skærmbillede af den præcise besked, før du ændrer politikken.

Denne distinktion er vigtig. Execution policy kan hjælpe med at forhindre utilsigtet scriptkørsel, men at indstille RemoteSigned eller Bypass gør ikke et script troværdigt. Gennemgå scriptet og dets kilde først.

Trin 1: Identificér den effektive politik og hvert omfang

Kør disse to kommandoer:

Get-ExecutionPolicy

Get-ExecutionPolicy -List

Den første returnerer den effektive politik for den nuværende session. Den anden lister de politikker, der er anvendt på MachinePolicy, UserPolicy, Process, CurrentUser og LocalMachine. Microsoft anbefaler specifikt Get-ExecutionPolicy -List for at se de politikker, der kan påvirke sessionen. Se Get-ExecutionPolicy.

Tjek alle områder i stedet for at antage, at LocalMachine-værdien er den, der styrer sessionen.

Hvis MachinePolicy eller UserPolicy er defineret, skal du stoppe, før du forsøger at tvinge en lokal workaround. Disse værdier kommer fra gruppepolitik og kan tilsidesætte execution policy-indstillinger, der er foretaget med PowerShell. På en administreret arbejdsmaskine er det næste skridt normalt at følge organisationens proces eller kontakte IT.

Vælg løsningen efter behov, ikke efter den korteste kommando

Trin 2: Brug administratorrettigheder kun til en maskinbred ændring

Du behøver ikke at åbne en elevated PowerShell blot for at ændre CurrentUser- eller Process-omfanget. Microsoft angiver, at elevation er påkrævet, når man ændrer politikken for den lokale computer, dvs. LocalMachine. Dette er en nyttig afvejning: Hvis kun din brugerkonto har brug for lokal scripting, tilføjer ændring af alle brugeres politik omfang uden at tilføje fordel.

Run as administrator er passende for en bevidst LocalMachine-ændring, men det er unødvendigt for Process- eller CurrentUser-omfanget.

Anbefaling efter behov: Brug CurrentUser for en udviklerkonto, der regelmæssigt kører lokalt forfattede scripts. Reserver LocalMachine til en administrator, der bevidst ønsker, at samme indstilling skal påvirke alle brugere.

Trin 3: Overvej CurrentUser RemoteSigned til regelmæssig lokal scripting

For mange personlige udviklingsmaskiner er et praktisk vedvarende valg:

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned

RemoteSigned tillader lokale scripts at køre uden at kræve en signatur, mens scripts markeret som downloadet fra internettet kræver en troværdig digital signatur, medmindre du eksplicit unblocker filen. Det bevarer en nyttig distinktion mellem kode, du har oprettet lokalt, og kode opnået fra en anden kilde.

Denne illustration viser en maskinbred RemoteSigned-kommando, fordi omfanget er udeladt; LocalMachine er standardomfanget. Foretræk et eksplicit omfang, så påvirkningen er bevidst.

En almindelig fejl er at køre Set-ExecutionPolicy RemoteSigned uden -Scope. Microsoft dokumenterer LocalMachine som standardomfanget, når man indstiller execution policy. Derfor er det bedre at være eksplicit:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Ændringen er effektiv med det samme; PowerShell behøver ikke at genstartes for CurrentUser- eller LocalMachine-ændringer.

Trin 4: Foretræk et Process-omfang for en midlertidig session

Hvis du fejlfinder eller kører et troværdigt lokalt script én gang, skal du undgå en vedvarende bruger- eller maskinændring. Et smallere valg er:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned

Process-omfanget gælder kun for den nuværende PowerShell-session. Microsoft angiver, at det gemmes i $Env:PSExecutionPolicyPreference-miljøvariablen og slettes, når processen lukkes.

Hvis en større applikation, installer eller kontrolleret automatiseringsmiljø allerede har sin egen sikkerhedsmodel, tilbyder PowerShell også Bypass:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

Process-omfang Bypass forsvinder, når PowerShell-processen lukkes, men det fjerner også execution policy-advarsler og blokering for den session.

Afvejning: Process-omfang minimerer vedvarende effekt, men Bypass er bredere end RemoteSigned inde i den session. Microsoft beskriver Bypass som at blokere intet og vise ingen advarsler eller prompter, og siger, at det er beregnet til scenarier, hvor en anden applikation leverer sikkerhedsmodellen. Til en normal interaktiv fejlfindingssession skal du bruge Process RemoteSigned først, medmindre du har en specifik grund til Bypass.

For en separat engangs Windows PowerShell-proces kan du også starte:

powershell.exe -ExecutionPolicy RemoteSigned -File .\script.ps1

For PowerShell 7 er den kørbare fil pwsh.exe. En kommandolinje execution policy-indstilling tilsidesætter stadig ikke en execution policy håndhævet af gruppepolitik.

Trin 5: Hvis RemoteSigned blokerer et downloadet script, unblock kun den fil

RemoteSigned behandler filer markeret som oprindende fra internettet anderledes. Microsoft dokumenterer Unblock-File-cmdletten som fjernelse af det internetzone-mærke, hvilket tillader et gennemgået usigneret script at køre under RemoteSigned.

Undersøg scriptet først. Hvis du stoler på kilden og har gennemgået indholdet, skal du køre:

Unblock-File -Path .\script.ps1

Du kan også bruge Unblock-afkrydsningsfeltet i filens Egenskaber-dialogboks. Microsoft angiver, at Unblock-File udfører den samme grundlæggende operation. Se Unblock-File.

At unblocke ét gennemgået downloadet script er smallere end at svække politikken for alle scripts på maskinen.

Du kan tjekke, om en fil har en Zone.Identifier alternativ datastrøm med:

Get-Item .\script.ps1 -Stream Zone.Identifier -ErrorAction SilentlyContinue

Microsoft bemærker, at downloadmetoder ikke alle markerer filer på samme måde, så fraværet af den strøm er ikke bevis for, at et script er sikkert.

Trin 6: Brug AllSigned, når organisationen har en signeringsarbejdsgang

AllSigned kræver, at alle scripts og konfigurationsfiler er signeret af en troværdig udgiver, inklusive scripts oprettet lokalt. Det giver en organisation en konsistent udgiver-tillidsarbejdsgang, men det skaber også driftsomkostninger: scripts har brug for Authenticode-signaturer, og brugere skal stole på de relevante udgivere.

Microsofts about_Signing-dokumentation forklarer, hvordan PowerShell tjekker script-signaturer, og hvordan prompter for troværdige udgivere fungerer.

Anbefaling efter behov: AllSigned giver mening, når din organisation allerede har kode-signeringscertifikater, publiceringskontroller og en proces til opdatering af signerede scripts. For en enkelt udvikler, der skriver lokale hjælpeprogram-scripts, indebærer RemoteSigned normalt mindre friktion, mens den stadig bevarer internetoprindelseskontrollen.

Trin 7: Bekæmp ikke gruppepolitik på en administreret PC

PowerShell eksponerer to politikområder, der kommer fra gruppepolitik: MachinePolicy og UserPolicy. Microsofts gruppepolitikdokumentation siger, at indstillingen Turn on Script Execution kan håndhæve Restricted-, RemoteSigned- eller AllSigned-adfærd for administrerede brugere og computere. Indstillingen er under:

Administrative Templates\Windows Components\Windows PowerShell

Se about_Group_Policy_Settings.

Hvis Get-ExecutionPolicy -List viser en defineret MachinePolicy eller UserPolicy, kan en lokal Set-ExecutionPolicy-kommando måske ikke give dig den effektive adfærd, du forventer. Den praktiske løsning er at anmode om den korrekte politik fra administratoren, bruge et signeret script, hvis det kræves, eller bruge en godkendt udrullingsmetode.

Trin 8: Gendan den indstilling, du faktisk ændrede, og verificér derefter

Før du ændrer et vedvarende omfang, skal du registrere dets eksisterende værdi:

Get-ExecutionPolicy -Scope CurrentUser

Get-ExecutionPolicy -Scope LocalMachine

Hvis du senere har brug for at fjerne en politikværdi, du har indstillet, dokumenterer Microsoft at indstille det omfang til Undefined:

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy Undefined

Kør ikke blindt Set-ExecutionPolicy Restricted, bare fordi et skærmbillede viser det. Uden et omfang retter kommandoen sig mod LocalMachine som standard, og “Restricted” var måske ikke den tidligere værdi for det omfang.

Skærmbilledet illustrerer en Restricted-ændring, men en reel tilbagerulning bør gendanne det omfang og den værdi, du registrerede, i stedet for at gætte den tidligere konfiguration.

Verificér til sidst både den effektive politik og scriptet:

Get-ExecutionPolicy

Get-ExecutionPolicy -List

.\script.ps1

En vellykket scriptkørsel bekræfter, at det umiddelbare symptom er løst; genkontrollér politiklisten for at bekræfte, at du ikke har efterladt et bredere omfang ændret utilsigtet.

Hvilken løsning skal du vælge?

Almindelige fejl, der skaber et større problem end den oprindelige fejl

• At indstille Unrestricted eller Bypass permanent blot for at få ét script til at køre. Dette udvider, hvad der kan køre, når en smallere Process-, CurrentUser- eller filspecifik ændring måske løser problemet.
• At køre alle kommandoer som Administrator. CurrentUser- og Process-ændringer behøver ikke en LocalMachine-politikændring.
• At ignorere gruppepolitik. Hvis enheden er administreret, kan politikken være tilsigtet, og lokal ændring af et andet omfang erstatter ikke organisationskontrol.
• At unblocke et script uden at læse det. Unblock-File fjerner internetoprindelsesblokken; det validerer ikke koden.
• At antage, at et signeret script automatisk er harmløst. Microsoft bemærker, at signeret kode stadig kan være ondsindet; signaturer etablerer udgiver- og integritetsinformation, ikke en garanti for sikker adfærd.
• At glemme, hvilket omfang du ændrede. En kommando uden -Scope kan påvirke LocalMachine, mens en Process-ændring forsvinder ved afslutning.

Konklusion

For de fleste personlige Windows-scripting er CurrentUser RemoteSigned et rimeligt vedvarende valg, når du rutinemæssigt kører lokalt oprettede scripts, mens Unblock-File er det smallere valg for ét gennemgået script downloadet fra internettet. Til en midlertidig fejlfindingssession minimerer Process RemoteSigned vedvarende effekt. Bypass har en legitim rolle i kontrolleret automatisering, men dets afvejning er, at execution policy-blokering og advarsler fjernes for den proces. På administrerede computere bør gruppepolitik behandles som myndigheden snarere end som en forhindring, der skal omgås.

Den bedste løsning er derfor ikke én politik for alle. Det er det mindste omfang og den mindst tilladelige adfærd, der stadig understøtter det troværdige script, du har brug for at køre.