Prüfen Sie zunächst, welche Richtlinie aktuell greift. Das Cmdlet "Get-ExecutionPolicy" liefert einen ersten Überblick, doch PowerShell kennt mehrere Geltungsbereiche gleichzeitig – vom lokalen Rechner bis zum aktuellen Prozess. Wer genauer hinschauen will, nutzt "Get-ExecutionPolicy -List" und sieht auf einen Blick, welche Richtlinie in welchem Scope (MachinePolicy, UserPolicy, Process, CurrentUser, LocalMachine) aktiv ist:

Get-ExecutionPolicy -List

Die Ausführungsrichtlinie "Restricted" blockiert sämtliche Skripte und bremst damit auch legitime Automatisierung aus. Am anderen Ende der Skala erlaubt "Bypass" jeden Code ohne Rückfrage und öffnet damit Tür und Tor für schädliche Skripte. Einen praxistauglichen Mittelweg bietet "RemoteSigned": Skripte ohne "Mark of the Web", also ohne Kennzeichnung als Internet-Download, laufen ohne Umschweife, während markierte Skripte eine gültige digitale Signatur eines vertrauenswürdigen Herausgebers brauchen. Wer noch strenger arbeiten möchte, greift zu "AllSigned" und verlangt eine Signatur ausnahmslos, auch für selbst geschriebene Skripte.

Zum Umsetzen öffnen Sie die PowerShell-Konsole oder die PowerShell ISE mit Administratorrechten und setzen die Richtlinie gezielt für den gewünschten Geltungsbereich:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine

Wollen Sie auch heruntergeladene oder von extern kopierte Skripte mit eigenem Zertifikat ausführen, reicht die Richtlinienänderung allein nicht aus. Importieren Sie das selbst erstellte Zertifikat zusätzlich in den Speicher "Vertrauenswürdige Stammzertifizierungsstellen" beziehungsweise "Vertrauenswürdige Herausgeber" des lokalen Rechners. Erst dann erkennt Windows die Signatur als vertrauenswürdig an.

Ein wichtiger Hinweis für die Praxis: Die Ausführungsrichtlinie ist kein echter Sicherheitsmechanismus, sondern eher eine Leitplanke gegen versehentliches Ausführen von Skripten. Mit dem Parameter "-ExecutionPolicy Bypass" beim Start von PowerShell oder mit lokalen Administratorrechten lässt sie sich umgehen. Wer echten Schutz vor bösartigem Code braucht, kombiniert die Richtlinie deshalb mit zusätzlichen Maßnahmen wie AppLocker, Windows Defender Application Control oder dem Constrained Language Mode.