Så här åtgärdar du felet "Execution Policy Restricted" i Windows PowerShell

Det säkraste sättet att åtgärda ett "Execution Policy Restricted"-fel i Windows PowerShell är inte att kopiera det bredaste kommandot du kan hitta. Identifiera först vilken körningspolicy som faktiskt är aktiv, välj sedan den smalaste ändringen som passar det du försöker köra.

Microsofts aktuella dokumentation betonar också att versionskontext är viktig. Dokumentationen för Windows PowerShell 5.1 listar Restricted som standardkörningspolicy för Windows-klientdatorer. Den aktuella dokumentationen för PowerShell 7.6 definierar Default som RemoteSigned på Windows. Om alla omfång är Undefined dokumenterar Microsoft dock fortfarande den effektiva reservlösningen på Windows-klienter som Restricted. Den praktiska lärdomen är enkel: dra inte slutsatser om din policy utifrån din Windows-version eller från en handledning. Kör policykommandona på den dator som har felet.

Den här guiden jämför de viktigaste lösningarna utifrån omfång, beständighet, administrativ påverkan och förtroendemodell. Målet är att få ett legitimt skript att köras utan att försvaga mer av systemet än nödvändigt.

Vad felet "Restricted" egentligen betyder

Under policyn Restricted tillåter PowerShell individuella kommandon men tillåter inte att skriptfiler körs. Det inkluderar PowerShell-skript och relaterade konfigurations- eller moduls-skriptfiler. Microsoft beskriver körningspolicy som en säkerhetsfunktion som styr under vilka villkor skript och konfigurationsfiler laddas. Det är inte en säkerhetsgräns; Microsoft noterar uttryckligen att en användare fortfarande kan skriva in kommandon interaktivt. Läs den aktuella dokumentationen om about_Execution_Policies för PowerShell 7.6 och dokumentationen om körningspolicy för Windows PowerShell 5.1.

Det vanliga felet säger att .ps1-filen inte kan laddas eftersom körning av skript är inaktiverat; fånga exakt meddelande innan du ändrar policyn.

Den distinktionen är viktig. Körningspolicy kan hjälpa till att förhindra oavsiktlig skriptkörning, men att ställa in RemoteSigned eller Bypass gör inte ett skript pålitligt. Granska skriptet och dess källa först.

Steg 1: Identifiera den effektiva policyn och alla omfång

Kör dessa två kommandon:

Get-ExecutionPolicy

Get-ExecutionPolicy -List

Det första returnerar den effektiva policyn för den aktuella sessionen. Det andra listar de policyer som tillämpas på MachinePolicy, UserPolicy, Process, CurrentUser och LocalMachine. Microsoft rekommenderar specifikt Get-ExecutionPolicy -List för att se de policyer som kan påverka sessionen. Se Get-ExecutionPolicy.

Kontrollera alla omfång istället för att anta att värdet för LocalMachine är det som styr sessionen.

Om MachinePolicy eller UserPolicy är definierat, stoppa innan du försöker tvinga fram en lokal lösning. Dessa värden kommer från grupprincip och kan åsidosätta inställningar för körningspolicy som gjorts med PowerShell. På en hanterad arbetsdator är nästa steg vanligtvis att följa organisationens process eller kontakta IT.

Välj lösning efter behov, inte efter det kortaste kommandot

Steg 2: Använd administratörsrättigheter endast för en maskinomfattande ändring

Du behöver inte öppna en förhöjd PowerShell enbart för att ändra omfånget CurrentUser eller Process. Microsoft säger att behörighetshöjning krävs när du ändrar policyn för den lokala datorn, det vill säga LocalMachine. Detta är en användbar avvägning: om bara ditt användarkonto behöver lokal skriptning, lägger en ändring av alla användares policy till omfång utan att tillföra nytta.

Kör som administratör är lämpligt för en avsiktlig LocalMachine-ändring, men det är onödigt för Process- eller CurrentUser-omfånget.

Rekommendation efter behov: använd CurrentUser för ett utvecklar-konto som regelbundet kör lokalt författade skript. Reservera LocalMachine för en administratör som avsiktligt vill att samma inställning ska påverka alla användare.

Steg 3: Överväg CurrentUser RemoteSigned för regelbunden lokal skriptning

För många personliga utvecklingsdatorer är ett praktiskt beständigt val:

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned

RemoteSigned tillåter lokala skript att köras utan att kräva en signatur, medan skript som markerats som nedladdade från internet kräver en betrodd digital signatur om du inte uttryckligen avblockerar filen. Det bevarar en användbar distinktion mellan kod du skapat lokalt och kod som erhållits från en annan källa.

Denna illustration visar ett maskinomfattande RemoteSigned-kommando eftersom omfånget utelämnas; LocalMachine är standardomfånget. Föredra ett uttryckligt omfång så att påverkan är avsiktlig.

Ett vanligt misstag är att köra Set-ExecutionPolicy RemoteSigned utan -Scope. Microsoft dokumenterar LocalMachine som standardomfånget när du ställer in körningspolicy. Därför är det bättre att vara uttrycklig:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Ändringen är effektiv omedelbart; PowerShell behöver inte startas om för ändringar av CurrentUser eller LocalMachine.

Steg 4: För en tillfällig session, föredra en policy med Process-omfång

Om du felsöker eller kör ett betrott lokalt skript en gång, undvik en beständig användar- eller maskinändring. Ett smalare alternativ är:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned

Omfattningen Process gäller endast för den aktuella PowerShell-sessionen. Microsoft säger att den lagras i miljövariabeln $Env:PSExecutionPolicyPreference och raderas när processen avslutas.

Om en större applikation, installerare eller kontrollerad automatiseringsmiljö redan har sin egen säkerhetsmodell, tillhandahåller PowerShell också Bypass:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

Process-omfattande Bypass försvinner när PowerShell-processen avslutas, men det tar också bort körningspolicyvarningar och blockering för den sessionen.

Avvägning: Process-omfånget minimerar beständighet, men Bypass är bredare än RemoteSigned inuti den sessionen. Microsoft beskriver Bypass som att inte blockera något och inte visa varningar eller uppmaningar, och säger att det är avsett för scenarier där en annan applikation tillhandahåller säkerhetsmodellen. För en normal interaktiv felsökningssession, använd Process RemoteSigned först om du inte har en specifik anledning till Bypass.

För en separat engångsprocess för Windows PowerShell kan du också starta:

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

För PowerShell 7 är körbara filen pwsh.exe. En inställning av körningspolicy via kommandoraden åsidosätter fortfarande inte en körningspolicy som tillämpas av grupprincip.

Steg 5: Om RemoteSigned blockerar ett nedladdat skript, avblockera endast den filen

RemoteSigned behandlar filer som markerats som ursprungliga från internet annorlunda. Microsoft dokumenterar cmdleten Unblock-File som att den tar bort den internetzonmarkeringen, vilket tillåter ett granskat osignerat skript att köras under RemoteSigned.

Inspektera skriptet först. Om du litar på källan och har granskat innehållet, kör:

Unblock-File -Path .\script.ps1

Du kan också använda kryssrutan Avblockera i filens Egenskaper-dialogruta. Microsoft anger att Unblock-File utför samma grundläggande operation. Se Unblock-File.

Att avblockera ett granskat nedladdat skript är smalare än att försvaga policyn för alla skript på datorn.

Du kan kontrollera om en fil har en alternativ dataström för Zone.Identifier med:

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

Microsoft noterar att nedladdningsmetoder inte alla markerar filer på samma sätt, så frånvaron av den strömmen är inte bevis på att ett skript är säkert.

Steg 6: Använd AllSigned när organisationen har ett signeringsarbetsflöde

AllSigned kräver att alla skript och konfigurationsfiler signeras av en betrodd utgivare, inklusive skript som skapats lokalt. Det ger en organisation ett konsekvent utgivarförtroendearbetsflöde, men det skapar också operativt överhuvud: skript behöver Authenticode-signaturer och användare behöver lita på de relevanta utgivarna.

Microsofts dokumentation om about_Signing förklarar hur PowerShell kontrollerar skriptsignaturer och hur uppmaningar om betrodda utgivare fungerar.

Rekommendation efter behov: AllSigned är meningsfullt när din organisation redan har kodsigneringscertifikat, publiceringskontroller och en process för att uppdatera signerade skript. För en ensam utvecklare som skriver lokala verktygsskript, innebär RemoteSigned vanligtvis mindre friktion medan den fortfarande bevarar kontrollen av internetursprung.

Steg 7: Bekämpa inte grupprincip på en hanterad PC

PowerShell exponerar två policyomfång som kommer från grupprincip: MachinePolicy och UserPolicy. Microsofts dokumentation om grupprincip säger att inställningen Aktivera skriptkörning kan tillämpa beteendet Restricted, RemoteSigned eller AllSigned för hanterade användare och datorer. Inställningen finns under:

Administrative Templates\Windows Components\Windows PowerShell

Se about_Group_Policy_Settings.

Om Get-ExecutionPolicy -List visar en definierad MachinePolicy eller UserPolicy, kan ett lokalt Set-ExecutionPolicy-kommando ge dig det effektiva beteendet du förväntar dig. Den praktiska lösningen är att begära lämplig policy från administratören, använda ett signerat skript om det krävs, eller använda en godkänd distributionsmetod.

Steg 8: Återställ den inställning du faktiskt ändrade, verifiera sedan

Innan du ändrar ett beständigt omfång, registrera dess befintliga värde:

Get-ExecutionPolicy -Scope CurrentUser

Get-ExecutionPolicy -Scope LocalMachine

Om du senare behöver ta bort ett policyvärde du ställt in, dokumenterar Microsoft att ställa in det omfånget till Undefined:

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy Undefined

Kör inte blindt Set-ExecutionPolicy Restricted bara för att en skärmdump visar det. Utan omfång riktar kommandot sig mot LocalMachine som standard, och "Restricted" kanske inte var det omfångets tidigare värde.

Skärmdumpen illustrerar en Restricted-ändring, men en riktig återställning bör återställa det omfång och värde du registrerade istället för att gissa den tidigare konfigurationen.

Verifiera slutligen både den effektiva policyn och skriptet:

Get-ExecutionPolicy

Get-ExecutionPolicy -List

.\script.ps1

En framgångsrik skriptkörning bekräftar att det omedelbara symtomet är åtgärdat; kontrollera policylistan igen för att bekräfta att du inte lämnade ett bredare omfång oavsiktligt ändrat.

Vilken lösning bör du välja?

Vanliga misstag som skapar ett större problem än det ursprungliga felet

• Att ställa in Unrestricted eller Bypass permanent bara för att få ett skript att köras. Detta vidgar vad som kan köras när en smalare Process-, CurrentUser- eller filspecifik ändring kan lösa problemet.
• Att köra varje kommando som Administratör. Ändringar av CurrentUser och Process kräver inte en policyändring för LocalMachine.
• Att ignorera grupprincip. Om enheten är hanterad kan policyn vara avsiktlig och en lokal ändring av ett annat omfång ersätter inte organisationskontroll.
• Att avblockera ett skript utan att läsa det. Unblock-File tar bort blockeringen för internetursprung; det validerar inte koden.
• Att anta att ett signerat skript automatiskt är ofarligt. Microsoft noterar att signerad kod fortfarande kan vara skadlig; signaturer etablerar utgivare- och integritetsinformation, inte en garanti för säkert beteende.
• Att glömma vilket omfång du ändrade. Ett kommando utan -Scope kan påverka LocalMachine, medan en Process-ändring försvinner vid avslutning.

Slutsats

För de flesta personliga Windows-skript är CurrentUser RemoteSigned ett rimligt beständigt val när du rutinmässigt kör lokalt skapade skript, medan Unblock-File är det smalare valet för ett granskat skript nedladdat från internet. För en tillfällig felsökningssession minimerar Process RemoteSigned beständighet. Bypass har en legitim roll i kontrollerad automatisering, men dess avvägning är att körningspolicyblockering och varningar tas bort för den processen. På hanterade datorer bör grupprincip behandlas som auktoritet snarare än ett hinder att kringgå.

Den bästa lösningen är därför inte en policy för alla. Det är det minsta omfånget och det minst tillåtande beteendet som fortfarande stöder det betrodda skript du behöver köra.