Ein Skript startet nicht, weil die Ausführung deaktiviert sei? Das ist kein Defekt, sondern eine Schutzeinstellung — mit bewusst gewähltem Ausweg.
Aufwand:
ca. 15 Min.
Das Symptom
Beim Versuch, ein PowerShell-Skript auszuführen, erscheint rot die Meldung, dass die
Ausführung von Skripten auf diesem System deaktiviert sei (running scripts is disabled on this system), samt Verweis auf die Ausführungsrichtlinie. Das Skript
startet gar nicht erst.
Die „Layer 8“-Wahrheit
Diese Sperre ist mit voller Absicht der Standard. PowerShell ist mächtig genug, um
ein System umzukrempeln, und genau deshalb sollen nicht beliebige Skripte per
Doppelklick durchlaufen — sonst wäre ein untergeschobenes Schadskript ein Kinderspiel.
Die Meldung ist also kein Fehler, den man „reparieren“ muss, sondern eine Wache, die
fragt, ob man wirklich weiß, was man da ausführt.
Die richtige Reaktion ist deshalb nicht, die Sperre reflexartig komplett abzuschalten,
sondern maßvoll aufzumachen. Für den Alltag genügt meist die Stufe RemoteSigned nur
für den eigenen Benutzer: Eigene, lokale Skripte laufen, während alles aus dem
Internet eine Signatur braucht. Für einen einzelnen Lauf reicht es, die Richtlinie
nur für dieses eine Fenster zu umgehen. Was man dagegen niemals tun sollte, ist ein
fremdes, ungeprüftes Skript blind freizuschalten — denn dann hat die Wache umsonst
gewarnt.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.
Die Schutzeinstellung verstehen
Die Ausführungsrichtlinie (Execution Policy) verhindert, dass beliebige Skripte einfach so laufen — ein Schutz gegen untergeschobene Schadskripte. Die Meldung ist also kein Fehler, sondern die Richtlinie, die ihre Arbeit tut. Zuerst den aktuellen Stand ansehen:
Get-ExecutionPolicy -List
2.
Die Herkunft des Skripts hinterfragen
Bevor man die Sperre lockert: Stammt das Skript aus einer vertrauenswürdigen Quelle? Ein aus dem Internet geladenes, ungeprüftes Skript blind auszuführen ist genau das, wovor die Richtlinie schützt. Nur ausführen, was man versteht oder dem man traut.
3.
Die Richtlinie für den eigenen Benutzer maßvoll setzen
Ein guter Kompromiss ist RemoteSigned nur für den aktuellen Benutzer: Lokale Skripte laufen, aus dem Internet geladene müssen signiert sein. Das erfordert keine Administratorrechte für das ganze System:
Soll ein Skript nur einmal laufen, ohne die dauerhafte Einstellung zu ändern, die Richtlinie allein für den aktuellen Prozess umgehen. Nach dem Schließen des Fensters ist alles wie vorher:
Manchmal ist nur eine einzelne, aus dem Internet geladene Datei markiert. Diese Markierung lässt sich gezielt für die eine Datei entfernen, ohne die Richtlinie generell zu senken:
Unblock-File .\skript.ps1
Häufige Fragen (FAQ)
?PowerShell führt mein Skript nicht aus. Ist das ein Fehler?
Nein, das ist der eingebaute Schutz. Standardmäßig darf PowerShell keine Skriptdateien ausführen – genau das verhindert, dass eine per Mail zugestellte .ps1-Datei mit einem Doppelklick Schaden anrichtet. Die Blockade ist die Voreinstellung, nicht ein Defekt.
?Was ist die sicherste Art, ein einzelnes vertrauenswürdiges Skript auszuführen?
Die Richtlinie nur für die aktuelle Sitzung zu öffnen, statt sie systemweit zu ändern: Damit gilt die Ausnahme genau einmal und ist nach dem Schließen des Fensters wieder weg. Wer die Richtlinie dauerhaft setzt, sollte höchstens RemoteSigned für den eigenen Benutzer wählen – niemals Unrestricted für das gesamte System.
Belege
Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.
SSH warnt 'REMOTE HOST IDENTIFICATION HAS CHANGED' und 'Host key verification failed'? So prüfst du die Ursache und entfernst den alten Schlüssel sicher.