Slik løser du feilen «Execution Policy Restricted» i Windows PowerShell

Den sikreste måten å løse en «Execution Policy Restricted»-feil i Windows PowerShell på, er ikke å kopiere den bredeste kommandoen du finner. Identifiser først hvilken utførelsespolicy som faktisk er gjeldende, og velg deretter den mest avgrensede endringen som passer til det du prøver å kjøre.

Microsofts gjeldende dokumentasjon understreker også viktigheten av versjonskontekst. Dokumentasjonen for Windows PowerShell 5.1 lister Restricted som standard utførelsespolicy for Windows-klientmaskiner. Gjeldende dokumentasjon for PowerShell 7.6 definerer Default som RemoteSigned på Windows. Hvis alle omfang er Undefined, dokumenterer Microsoft likevel at den gjeldende reserveløsningen på Windows-klienter er Restricted. Den praktiske læren er enkel: ikke anta policyen din basert på Windows-versjonen eller en veiledning. Kjør policykommandoene på maskinen som har feilen.

Denne veiledningen sammenligner de viktigste løsningene basert på omfang, varighet, administrativ påvirkning og tillitsmodell. Målet er å få en legitim skript til å kjøre uten å svekke mer av systemet enn nødvendig.

Hva Restricted-feilen faktisk betyr

Under Restricted-policyen tillater PowerShell individuelle kommandoer, men tillater ikke at skriptfiler kjører. Det inkluderer PowerShell-skript og relaterte konfigurasjons- eller moduls-skriptfiler. Microsoft beskriver utførelsespolicy som en sikkerhetsfunksjon som styrer betingelsene under hvilke skript og konfigurasjonsfiler lastes. Det er ikke en sikkerhetsgrense; Microsoft merker eksplisitt at en bruker fortsatt kan skrive kommandoer interaktivt. Les den gjeldende about_Execution_Policies-dokumentasjonen for PowerShell 7.6 og Windows PowerShell 5.1-dokumentasjonen for utførelsespolicy.

Den vanlige feilmeldingen sier at .ps1-filen ikke kan lastes fordi skriptkjøring er deaktivert; ta vare på den nøyaktige meldingen før du endrer policyen.

Denne distinksjonen er viktig. Utførelsespolicy kan hjelpe med å forhindre utilsiktet skriptkjøring, men å sette RemoteSigned eller Bypass gjør ikke et skript pålitelig. Gå gjennom skriptet og dets kilde først.

Trinn 1: Identifiser den gjeldende policyen og hvert omfang

Kjør disse to kommandoene:

Get-ExecutionPolicy

Get-ExecutionPolicy -List

Den første returnerer den gjeldende policyen for den nåværende sesjonen. Den andre lister policyene som er anvendt på MachinePolicy, UserPolicy, Process, CurrentUser og LocalMachine. Microsoft anbefaler Get-ExecutionPolicy -List spesifikt for å se policyene som kan påvirke sesjonen. Se Get-ExecutionPolicy.

Sjekk alle omfang i stedet for å anta at LocalMachine-verdien er den som styrer sesjonen.

Hvis MachinePolicy eller UserPolicy er definert, stopp før du prøver å tvinge frem en lokal omgåelse. Disse verdiene kommer fra gruppepolicy og kan overstyre utførelsespolicyinnstillinger gjort med PowerShell. På en administrert arbeidsdatamaskin er det riktige neste steget vanligvis å følge organisasjonens prosess eller kontakte IT.

Velg løsningen basert på behov, ikke den korteste kommandoen

Trinn 2: Bruk administratorrettigheter kun for en maskinomfattende endring

Du trenger ikke å åpne en hevet PowerShell kun for å endre CurrentUser- eller Process-omfanget. Microsoft sier at heving er nødvendig når du endrer policyen for den lokale datamaskinen, det vil si LocalMachine. Dette er en nyttig avveining: hvis bare din brukerkonto trenger lokal skripting, legger endring av policyen for alle brukere til omfang uten å legge til nytte.

Kjør som administrator er hensiktsmessig for en bevisst LocalMachine-endring, men det er unødvendig for Process- eller CurrentUser-omfang.

Anbefaling etter behov: bruk CurrentUser for en utviklerkonto som jevnlig kjører lokalt forfattede skript. Reserver LocalMachine for en administrator som bevisst ønsker at samme innstilling skal påvirke alle brukere.

Trinn 3: For vanlig lokal skripting, vurder CurrentUser RemoteSigned

For mange personlige utviklingsmaskiner er et praktisk varig valg:

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned

RemoteSigned tillater at lokale skript kjører uten å kreve en signatur, mens skript merket som nedlastet fra internett krever en pålitelig digital signatur med mindre du eksplisitt opphever blokkeringen av filen. Det bevarer en nyttig distinksjon mellom kode du opprettet lokalt og kode obtained fra en annen kilde.

Denne illustrasjonen viser en maskinomfattende RemoteSigned-kommando fordi omfanget er utelatt; LocalMachine er standard omfang. Foretrekk et eksplisitt omfang slik at påvirkningen er bevisst.

En vanlig feil er å kjøre Set-ExecutionPolicy RemoteSigned uten -Scope. Microsoft dokumenterer LocalMachine som standard omfang når du setter utførelsespolicy. Derfor er det bedre å være eksplisitt:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Endringen er umiddelbart gjeldende; PowerShell trenger ikke å startes på nytt for CurrentUser- eller LocalMachine-endringer.

Trinn 4: For en midlertidig sesjon, foretrekk en policy med Process-omfang

Hvis du feilsøker eller kjører et pålitelig lokalt skript én gang, unngå en varig bruker- eller maskinendring. Et mer avgrenset alternativ er:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned

Process-omfanget gjelder kun for den gjeldende PowerShell-sesjonen. Microsoft sier at det lagres i miljøvariabelen $Env:PSExecutionPolicyPreference og slettes når prosessen lukkes.

Hvis et større program, en installasjonsprogram eller et kontrollert automatiseringsmiljø allerede har sin egen sikkerhetsmodell, gir PowerShell også Bypass:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

Process-omfanget Bypass forsvinner når PowerShell-prosessene lukkes, men det fjerner også utførelsespolicy-advarsler og blokkering for den sesjonen.

Avveining: Process-omfang minimerer varighet, men Bypass er bredere enn RemoteSigned inne i den sesjonen. Microsoft beskriver Bypass som å ikke blokkere noe og ikke vise advarsler eller forespørsler, og sier at det er ment for scenarioer der et annet program gir sikkerhetsmodellen. For en normal interaktiv feilsøkingssesjon, bruk Process RemoteSigned først med mindre du har en spesifikk grunn til Bypass.

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

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

For PowerShell 7 er den kjorbare filen pwsh.exe. En kommandolinje-innstilling for utførelsespolicy overstyrer fortsatt ikke en utførelsespolicy håndhevet av gruppepolicy.

Trinn 5: Hvis RemoteSigned blokkerer et nedlastet skript, opphev blokkeringen kun for den filen

RemoteSigned behandler filer merket som opprinnelig fra internett forskjellig. Microsoft dokumenterer Unblock-File-cmdleten som å fjerne det internettsonemerket, noe som tillater et gjennomgått usignert skript å kjøre under RemoteSigned.

Undersøk skriptet først. Hvis du stoler på kilden og har gjennomgått innholdet, kjør:

Unblock-File -Path .\script.ps1

Du kan også bruke Unblock-avkryssingsboksen i filens Egenskaper-dialogboks. Microsoft sier at Unblock-File utfører den samme grunnleggende operasjonen. Se Unblock-File.

Å oppheve blokkeringen av ett gjennomgått nedlastet skript er mer avgrenset enn å svekke policyen for alle skript på maskinen.

Du kan sjekke om en fil har en alternativ datastrøm for Zone.Identifier med:

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

Microsoft merker at nedlastingsmetoder ikke markerer filer på samme måte, så fraværet av den strømmen er ikke bevis på at et skript er trygt.

Trinn 6: Bruk AllSigned når organisasjonen har en signeringsarbeidsflyt

AllSigned krever at alle skript og konfigurasjonsfiler er signert av en pålitelig utgiver, inkludert skript opprettet lokalt. Det gir en organisasjon en konsistent utgiver-tillitsarbeidsflyt, men det skaper også operasjonell overhead: skript trenger Authenticode-signaturer og brukere må stole på de relevante utgiverne.

Microsofts about_Signing-dokumentasjon forklarer hvordan PowerShell sjekker skriptsignaturer og hvordan forespørsler om pålitelige utgivere fungerer.

Anbefaling etter behov: AllSigned gir mening når organisasjonen din allerede har kodesigneringssertifikater, publiseringskontroller og en prosess for å oppdaterte signerte skript. For en enslig utvikler som skriver lokale verktøyskript, innebærer RemoteSigned vanligvis mindre friksjon mens den fortsatt bevarer sjekken for internett-opprinnelse.

Trinn 7: Ikke kjemp mot gruppepolicy på en administrert PC

PowerShell eksponerer to policy-omfang som kommer fra gruppepolicy: MachinePolicy og UserPolicy. Microsofts gruppepolicy-dokumentasjon sier at innstillingen Turn on Script Execution kan håndheve Restricted, RemoteSigned eller AllSigned-atferd for administrerte brukere og datamaskiner. Innstillingen finnes under:

Administrative Templates\Windows Components\Windows PowerShell

Se about_Group_Policy_Settings.

Hvis Get-ExecutionPolicy -List viser en definert MachinePolicy eller UserPolicy, kan en lokal Set-ExecutionPolicy-kommando kanskje ikke gi deg den gjeldende atferden du forventer. Den praktiske løsningen er å be administratoren om riktig policy, bruke et signert skript hvis nødvendig, eller bruke en godkjent distribusjonsmetode.

Trinn 8: Gjenopprett innstillingen du faktisk endret, og verifiser deretter

Før du endrer et varig omfang, registrer den eksisterende verdien:

Get-ExecutionPolicy -Scope CurrentUser

Get-ExecutionPolicy -Scope LocalMachine

Hvis du senere trenger å fjerne en policyverdi du satte, dokumenterer Microsoft å sette det omfanget til Undefined:

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy Undefined

Kjør ikke blindt Set-ExecutionPolicy Restricted bare fordi et skjermbilde viser det. Uten omfang retter kommandoen seg mot LocalMachine som standard, og «Restricted» var kanskje ikke den forrige verdien for det omfanget.

Skjermbildet illustrerer en Restricted-endring, men en ekte tilbakerulling bør gjenopprette omfanget og verdien du registrerte i stedet for å gjette den forrige konfigurasjonen.

Til slutt, verifiser både den gjeldende policyen og skriptet:

Get-ExecutionPolicy

Get-ExecutionPolicy -List

.\script.ps1

En vellykket skriptkjøring bekrefter at det umiddelbare symptomet er løst; sjekk policylisten på nytt for å bekrefte at du ikke etterlot et bredere omfang endret utilsiktet.

Hvilken løsning bør du velge?

Vanlige feil som skaper et større problem enn den opprinnelige feilen

• Å sette Unrestricted eller Bypass permanent bare for å få ett skript til å kjøre. Dette utvider hva som kan kjøre når en mer avgrenset Process-, CurrentUser- eller filspesifikk endring kanskje løser problemet.
• Å kjøre hver kommando som Administrator. CurrentUser- og Process-endringer trenger ikke en LocalMachine-policyendring.
• Å ignorere gruppepolicy. Hvis enheten er administrert, kan policyen være bevisst, og lokal endring av et annet omfang erstatter ikke organisatorisk kontroll.
• Å oppheve blokkeringen av et skript uten å lese det. Unblock-File fjerner blokkeringen for internett-opprinnelse; det validerer ikke koden.
• Å anta at et signert skript automatisk er ufarlig. Microsoft merker at signert kode fortsatt kan være ondsinnet; signaturer etablerer utgiver- og integritetsinformasjon, ikke en garanti for trygg atferd.
• Å glemme hvilket omfang du endret. En kommando uten -Scope kan påvirke LocalMachine, mens en Process-endring forsvinner ved avslutning.

Konklusjon

For de fleste personlige Windows-skript er CurrentUser RemoteSigned et rimelig varig valg når du jevnlig kjører lokalt opprettede skript, mens Unblock-File er det mer avgrensede valget for ett gjennomgått skript nedlastet fra internett. For en midlertidig feilsøkingssesjon minimerer Process RemoteSigned varighet. Bypass har en legitim rolle i kontrollert automatisering, men avveiningen er at utførelsespolicy-blokkering og advarsler fjernes for den prosessen. På administrerte datamaskiner bør gruppepolicy behandles som autoriteten snarere enn et hinder å omgå.

Den beste løsningen er derfor ikke én policy for alle. Det er det minste omfanget og den minst tillatelige atferden som fortsatt støtter det pålitelige skriptet du trenger å kjøre.