Execution Policy — Varför kan jag inte köra mitt PowerShell-skript?

Execution Policy är en säkerhetsmekanism i PowerShell som förhindrar att skadliga skript körs automatiskt. Men för många blir det bara ett irriterande problem när de försöker köra sina egna skript. Här förklarar jag vad det är, vilka nivåer som finns, och vilken du bör använda.

Du skriver ett PowerShell-skript. Du sparar det som .ps1. Du försöker köra det. Plötsligt får du ett felmeddelande:

File cannot be loaded because running scripts is disabled on this system.

Du blir frustrerad. Varför kan jag inte köra mitt eget skript på min egen dator?

Svaret är Execution Policy. Det är en Windows-säkerhet som säger "endast tillåten PowerShell ska köra skript". Men det är ofta uppsatt på ett sätt som gör det svårt för dig som faktisk utvecklare.

Låt oss förstå det och lösa det rätt.

Vad är Execution Policy?

Säkerhet kontra bekvämlighet

Execution Policy är Microsofts sätt att säga "vi vill inte att obehöriga skript körs på din dator". Det är därför Windows per default inte tillåter att skript körs.

Det är viktigt för säkerhet — om du laddar ner ett skadigt skript från internet bör det inte kunna köras automatiskt. Men det är irriterande när DU skriver ditt eget skript och vill köra det.

💡 Execution Policy är INTE antivirusskydd. Det är bara en restriktion på vad PowerShell tillåter köra.

SE DIN NUVARANDE POLICY

Get-ExecutionPolicy

# Se policy för alla scopes
Get-ExecutionPolicy -List

Kör detta kommando för att se vad du har nu.

De olika Execution Policy-nivåerna

Vad var och en betyder

Policy	Vad det gör	För utvecklare?
Restricted	Ingen skript kan köras alls. Bara kommandon.	❌ Kan inte
AllSigned	Bara skript signerade av ett tillitscertifikat.	❌ Kan inte (såvida du inte signerar)
RemoteSigned	Skript från internet måste signeras. Lokala skript OK.	✅ REKOMMENDERAD
Unrestricted	Alla skript kan köras (med varning).	✅ Fungerar, men osäker
Bypass	Ingen begränsning alls — allt körs.	⚠️ Mycket osäker

RemoteSigned är the sweet spot — den tillåter dina egna lokala skript men varnar för skript från internet. Det är vad du bör använda.

"Execution Policy är inte säkerhet — det är en påminnelse. Den stoppar inte en hacker, bara en oförskylld användare."

Scopes — olika nivåer av policy

Var gäller din policy?

Execution Policy kan ställas in på olika nivåer:

DE OLIKA SCOPES

# Process scope - bara denna PowerShell-session
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope Process

# CurrentUser scope - bara för denna användare
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

# LocalMachine scope - för hela datorn (kräver admin)
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine
      

Process = bara denna PowerShell-fönster
CurrentUser = denna användare på denna dator
LocalMachine = alla användare på denna dator (kräver admin)

Om du bara vill köra skript i detta fönster, använd Process-scope. Det är det snabbaste fixet.

Hur du fixar Execution Policy

Steg för steg

Snabb fix (bara denna session):

PROCESS-SCOPE (BARA DENNA SESSION)

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope Process

Kör detta i PowerShell och du kan köra skript i detta fönster. Nästa gång du öppnar PowerShell måste du göra det igen.

Permanent fix (denna användare):

CURRENTUSER-SCOPE (PERMANENT)

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Denna policy gäller varje gång du öppnar PowerShell från detta användarkonto. Du behöver inte admin-rättigheter.

Hela datorn (kräver admin):

LOCALMACHINE-SCOPE (ALLA ANVÄNDARE)

# Öppna PowerShell som Administrator först!
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine
      

Denna policy gäller för alla användare på datorn. Du måste köra PowerShell som Administrator.

💡 Börja med Process-scope för att testa. Om du ska arbeta mycket med PowerShell, ställ in CurrentUser permanent.

Vanliga misstag och missförstånd

Gränsen mellan säkerhet och praktik

Misstag 1: Ställa in Bypass för att "lösa problemet"

Många gör detta:

DÅLIGT - UNSAFE

Set-ExecutionPolicy Bypass

Det fungerar, men det är osäkert. Du säger till Windows "kör allt utan frågor". Om du laddar ner ett skadligt skript körs det utan varning.

BÄTTRE - BALANSERAD

Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

RemoteSigned är säkert OCH praktiskt. Använd detta istället.

Misstag 2: Tro att Execution Policy är antivirusskydd

Det är det inte. En hacker som har åtkomst till din dator kan helt enkelt ändra Execution Policy. Det är bara en påminnelse, inte säkerhet.

Misstag 3: Glömma -Scope och bara köra Set-ExecutionPolicy

DÅLIGT - KRÄVER ADMIN

Set-ExecutionPolicy RemoteSigned
# Detta försöker ändra LocalMachine och kräver admin
      

BÄTTRE - SPECIFIKT SCOPE

Set-ExecutionPolicy RemoteSigned -Scope CurrentUser
# Detta fungerar utan admin
      

Utan -Scope försöker PowerShell ändra LocalMachine-nivån, vilket kräver admin-rättigheter. Specifiera alltid scope!

⚠️ RemoteSigned är standarden. Aldrig Bypass eller AllSigned såvida du inte har en mycket god anledning.

Verkligt exempel från praktiken

Scenario: Du behöver köra ett PowerShell-skript på flera datorer

VERKLIGT EXEMPEL - SÄKER SETUP

# 1. Checka vad du har nu
Get-ExecutionPolicy -List

# 2. Ställ in permanent för denna användare
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser -Force

# 3. Verifiera att det fungerade
Get-ExecutionPolicy

# 4. Nu kan du köra ditt skript
.\myScript.ps1

# 5. Om du behöver köra på fjärrservrar, använd Invoke-Command
# (Det ignorerar lokal Execution Policy på fjärrservern)
Invoke-Command -ComputerName SERVER01 -ScriptBlock {
  & "C:\Scripts\myScript.ps1"
}
      

Med RemoteSigned kan du köra lokala skript utan problem. Fjärrskript måste signeras (eller du använder Invoke-Command).

Signering av skript — för högre säkerhet

Om du behöver AllSigned policy

Om din miljö kräver att alla skript signeras (vanligt i stora företag) kan du skriva under dina skript:

SIGNERA ETT SKRIPT

# 1. Skapa eller få ett code signing-certifikat
# 2. Signera skriptet
$cert = Get-ChildItem Cert:\CurrentUser\My -CodeSigningCert | Select-Object -First 1
Set-AuthenticodeSignature -FilePath C:\Scripts\myScript.ps1 -Certificate $cert

# 3. Verifiera signeringen
Get-AuthenticodeSignature -FilePath C:\Scripts\myScript.ps1
      

Detta är avancerat och behövs inte för personligt bruk — men det är bra att veta i företagsmiljöer.

Execution Policy på fjärrservrar

Det är annorlunda där

Om du använder Invoke-Command för att köra skript på fjärrservrar är Execution Policy på VARJE SERVER viktig. Du behöver RemoteSigned på alla servrar som ska köra skript.

STÄLL IN POLICY PÅ FJÄRRSERVER

# Från din dator
Invoke-Command -ComputerName SERVER01 -ScriptBlock {
  Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine -Force
}

# Verifiera
Invoke-Command -ComputerName SERVER01 -ScriptBlock {
  Get-ExecutionPolicy
}
      

// SNABB GUIDE: EXECUTION POLICY

Restricted = ingen skript alls (standard på många system)
RemoteSigned = lokala skript OK, internet-skript måste signeras (REKOMMENDERAD)
Unrestricted = alla skript OK (med varning)
AllSigned = bara signerade skript (företag)
Bypass = ingen begränsning (UNSAFE)
Process-scope = endast denna session
CurrentUser-scope = denna användare (permanent)
LocalMachine-scope = alla användare (kräver admin)

För- och nackdelar

Säkerhet kontra praktik

✓ Fördelar med policy

Skyddar mot oavsiktligt köra skadigt skript
Tvingar dig att tänka innan du kör något
Bra för företagsmiljöer
Kan konfigureras per användare/dator
RemoteSigned är bra balans
Du kan alltid se vad du har

✗ Nackdelar

Irriterande för utvecklare
Skyddar INTE mot hacker
Kan ändras av vem som helst
Många ställer in Bypass (osäkert)
Förvirrar nybörjare
Gäller inte Invoke-Command

// CHECKLIST: EXECUTION POLICY SETUP

Kontrollera din nuvarande policy: Get-ExecutionPolicy -List
Ställ in RemoteSigned för detta användarkonto
Testa att du kan köra ett lokalt skript
Aldrig använda Bypass (såvida du inte måste)
Om du ändrar LocalMachine — dokumentera varför
På servrar — ställ in samma policy överallt
Använd Process-scope för temporär testning

adamhalvars

Execution Policy — Varför kan jag inte köra mitt skript?

// SNABB GUIDE: EXECUTION POLICY

✓ Fördelar med policy

✗ Nackdelar

// CHECKLIST: EXECUTION POLICY SETUP