Adam DriscollDas ist wahrscheinlich eine der häufigsten Fragen zu PowerShell Universal. Warum funktioniert mein Skript in PowerShell Universal nicht genauso wie an einer PowerShell-Eingabeaufforderung? Dieser Beitrag liefert Kontext und Schritte, mit denen Sie Probleme erkennen können, die beim Ausführen Ihrer Skripte auf der Plattform auftreten.
PowerShell-Versionen
Sie müssen die Versionen kennen, die beim Ausführen von Skripten in PowerShell Universal im Spiel sind. Es ist leicht, unterschiedliche PowerShell-Versionen auszuwählen, stellen Sie also sicher, dass das Skript in der erwarteten Version läuft.
Die PowerShell-Versionen sind auf der Seite Platform > Environments aufgeführt. Wenn Sie PowerShell 7 aktualisieren, verwendet PowerShell Universal automatisch die Version am Standardpfad. Es ist auch möglich, PowerShell-7-Versionen parallel zu installieren und PowerShell Universal für mehrere Versionen zu konfigurieren.
Ein häufiges Problem sind Module, die in PowerShell 7 nicht nativ funktionieren. In diesem Fall greift Windows PowerShell Compatibility. Es wirkt, als würde alles wie erwartet laufen, im Hintergrund starten jedoch neue Windows-PowerShell-Prozesse. Jeder Runspace, der das Windows-PowerShell-Modul in der PowerShell-7-Umgebung verwendet, startet einen neuen Prozess. Das kann die Leistung erheblich beeinträchtigen.
Integrierte Umgebung
Die integrierte Umgebung ist eine Version des PowerShell-7-SDK, die in PowerShell Universal eingebaut ist. Sie ändert sich nicht, wenn Sie PowerShell auf dem Host aktualisieren. Sie ändert sich nur, wenn eine neue Version von PowerShell Universal die Version des PowerShell-SDK aktualisiert.
Die integrierte Umgebung ist schnell, weil sie keine externen Prozesse starten und nicht über einen RPC-Kanal kommunizieren muss. Der Nachteil ist, dass sie ein Single Point of Failure für alle Skripte, APIs und Dashboards ist, da sie denselben Prozessraum teilen. Außerdem können Assembly-Konflikte auftreten, wenn Sie viele Module laden, die gemeinsame .NET-Assemblies verwenden.
Das ist häufig bei der Bibliothek Newtonsoft.Json der Fall. Skripte, die eingebaute Module oder gar keine Module verwenden, eignen sich sehr gut für die integrierte Umgebung.
Berechtigungen und Privilegien
Ein Skript als lokaler Benutzer auf einem Rechner auszuführen kann sich stark davon unterscheiden, ein Skript in PowerShell Universal auszuführen, wenn es als Dienst oder in IIS gehostet wird. Sie müssen wissen, wo Ihre Module installiert sind, weil PowerShell Universal sie möglicherweise nicht am selben Ort findet.
Wenn Sie als Dienst hosten und das Modul mit dem Desktop interagieren muss (wie Selenium), müssen Sie den Dienst besonders sorgfältig konfigurieren.
IIS schränkt den Benutzer des Anwendungspools zusätzlich ein, indem die Privilegien des Kontos zur Laufzeit begrenzt werden. Der Zugriff auf bestimmte Verzeichnisse oder die Erhöhung auf ein anderes Benutzerkonto kann daher Probleme verursachen, selbst wenn der Benutzer Administrator ist. Ein Beispiel: New-WebServiceProxy funktioniert in IIS nicht, weil das Cmdlet C#-Dateien schreiben und von der Festplatte kompilieren will und der Anwendungspool dieses Privileg nicht hat.
Sie können die Terminal-Funktion von PowerShell Universal nutzen, um die aktuell konfigurierte Umgebung zu untersuchen und die Unterschiede zu sehen.
Benutzerdefinierte Hosts
PowerShell Universal hat zwei benutzerdefinierte Hosts. Der erste wird verwendet, wenn Skripte als Jobs laufen. Dieser Host bietet Funktionen wie das Warten auf Rückmeldungen und die Ausgabe in verschiedene Streams. Der zweite wird für alle anderen Operationen in PowerShell Universal verwendet. Er implementiert außer Protokollierung keine eigenen Host-Funktionen.
Wenn Sie Parameter vergessen oder den Benutzer mit etwas wie Read-Host um Rückmeldung bitten, in einem Host, der das nicht unterstützt, erhalten Sie Fehler. Es ist bewährte Praxis, diese Art der Interaktion in PowerShell Universal zu vermeiden.
Kurzlebiger Runspace-Zustand
PowerShell Universal verwendet Runspace-Pools für den Großteil der Funktionalität im System. Es erstellt Runspaces bei Bedarf und gibt sie frei, wenn sie nicht mehr gebraucht werden. Nach jeder Ausführung einer Funktion, etwa einer API oder eines Dashboard-Endpunkts, wird der Runspace-Zustand zurückgesetzt.
Das kann Skripte betreffen, die PowerShell-Funktionen wie Sitzungen oder Remoting nutzen. Sie können Sitzungen nicht über Endpunktaufrufe hinweg verwenden, es sei denn, Sie aktivieren die Funktion persistent runspace.
Lang laufender Prozess
PowerShell Universal ist darauf ausgelegt, über einen langen Zeitraum zu laufen. Wir räumen Ressourcen regelmäßig auf und recyceln Runspaces nach einer bestimmten Anzahl von Verwendungen oder nach einer bestimmten Zeit. Einige PowerShell-Module sind für diese Art von Ausführungsumgebung nicht gut geeignet. Sie erwarten, in einem PowerShell-Prozess zu laufen, der ein Skript aufruft und dann beendet wird.
Als Workaround können Sie Skripte als Jobs in externen Prozessen ausführen, damit alle Ressourcen nach Abschluss des Skripts freigegeben werden. Bestimmte Module wie PowerCLI und dbatools haben statische .NET-Klassen, die Zustand halten und Speicher verbrauchen können, selbst wenn Runspaces freigegeben wurden und die .NET-Garbage Collection gelaufen ist.
IIS kann Recycling-Funktionen bereitstellen, die den PowerShell-Universal-Prozess in Intervallen neu starten, wenn bestimmte Ressourcengrenzen erreicht werden oder wenn der Server nicht verwendet wird.
Secret Management
Die Secret-Management-Implementierung von PowerShell Universal basiert auf den Modulen Microsoft SecretManagement. Die Standardinstallation enthält das Kernmodul sowie mehrere Vault-Module.
Alle standardmäßig enthaltenen Vaults implementieren benutzerspezifische Speichermechanismen. Wenn Sie das Benutzerkonto des PowerShell-Universal-Dienstes ändern, können Sie nicht mehr auf Geheimnisse zugreifen. Das bedeutet auch: Wenn Sie Geheimnisse in Ihrer lokalen Umgebung als Ihr eigener Benutzer anlegen, kann PowerShell Universal wahrscheinlich nicht auf diese Geheimnisse zugreifen.
Fazit
Dieser Beitrag sollte Ihnen Kontext geben, um Probleme beim Ausführen von Skripten in PowerShell Universal zu erkennen.
Bereit zum Bauen? PowerShell Universal herunterladen.