Ich stelle mal ein Thema hier im Blog zur Diskussion, was vermutlich alle Administratoren im Server-Umfeld tangiert. Wie haltet ihr es mit der PowerShell als Systemadministrator? Ein Blog-Leser hat mich kontaktiert, weil er das Problem sieht, dass die in Windows mitgelieferte ISE mit der neuen PowerShell nicht mehr umgehen kann.
Anzeige
Eine Leseranfrage
Blog-Leser Michael R. hatte mich bereits Anfang Februar 2024 per Mail kontaktiert und auf das Thema angesprochen. In seiner Mail mit dem Betreff "Arbeiten mit Powershell für System-Admins" schrieb er mir:
Ich verfolge ihren Blog schon lange Zeit hätte eine Frage zum Thema "Arbeiten mit Powershell für System-Admins".
Bei mir hat damals (mittlerweile 25 Jahre) mit den klassischen Batch-Dateien, .bat und .cmd, begonnen. Mal schnell auf einem Server eine Batch-Datei erstellt und ausgeführt, mal auf einem anderen. Schnell und einfach.
Dann kam irgendwann VB-Script dazu und da war es ähnlich. Mal schnell einen 5-Zeiler erstellt und ausgeführt.
Ein Quantensprung war dann die Powershell mit dem dazugehörigen ISE-Editor. Über diesen war und ist es auch möglich mal schnell und einfach einen 5-Zeiler oder 10-Zeiler zu erstellt und zu startet. Es muss nichts installiert werden, …
So weit so normal. Das Scenario dürfte wohl jeder Administrator so kennen. Zum Problem wird der Zugriff auf die PowerShell aber, wenn nicht alle Module in der Zielumgebung installiert sind. Michael greift dies in folgenden Zeilen auf:
Ich bewege mich viel auf verschieden Servern und nicht immer sind alle Module installiert. Z.B. auf einem RDS-Server sind die RDS-Module installiert, welche auf einem DC fehlen und ein SQL ist wieder anderes.
Zudem habe ich von Remote aus nicht immer überall Zugriff.
Der ISE hat das bis jetzt sehr angenehm gemacht. Mit den neuen Powershell kann dieser leider nicht mehr umgehen und wird nicht mehr weiterentwickelt.
ISE unterstützt kein PowerShell 7.x
Ich gestehe, ich habe es nicht im Details verfolgt. Aber es wird von Microsoft im Supportdokument Migrieren von Windows PowerShell 5.1 zu PowerShell 7 mit Stand 24. Januar 2024 explizit bestätigt:
Die Windows PowerShell Integrated Scripting Environment (ISE) unterstützt nur Windows PowerShell. Visual Studio Code (VS Code) mit der PowerShell-Erweiterung ist die unterstützte Skriptumgebung für PowerShell 7.
Es ist also, wie Michael oben erwähnte: Die auf den Systemen vorhandene ISE ist für PowerShell 7 nicht mehr zu gebrauchen. Microsoft meint, man soll Visual Studio Code verwenden. Dazu schreibt Michael: Überall vsCode zu installieren ist doch auch keine Lösung.
Anzeige
Michael interessiert nun: "Jetzt meine Frage und ich hoffe ich bin mit diesem Thema nicht ganz allein: Wie arbeiten sie oder andere Kollegen? Oder was wird verwendet? Oder denke ich einfach zu ungeschickt?". Ich selbst kann zu diesem Thema nichts beitragen, aber vielleicht fühlt sich der eine oder andere Administrator aus der Leserschaft bemüßigt, seine Sicht der Dinge bzw. Erfahrungen diesbezüglich in den Kommentaren darzustellen. Speziell: "Welche Entwicklungsumgebung wird bei euch zum PowerShell-Scripten eingesetzt?"
Ergänzung: Auf Facebook gab es in der Win-Administratorengruppe den Hinweis, dass man auf einem Server nicht entwickelt, sondern eine Workstation dazu nutzt. Dann stellt sich das Problem nicht.
Anzeige
Notepad++ existiert. Gestartet wird dann halt in der parallel offenen PowerShell.
Genau so.
Universellen Editor der Wahl nehmen (am besten mit Syntaxhervorhebung), als PS1 speichern und in einer Powershell ausführen.
Notepad++ ist hier auch mein Mittel der Wahl.
Visual Studio Code auf der PAW.
https://learn.microsoft.com/de-de/powershell/scripting/dev-cross-plat/vscode/using-vscode?view=powershell-7.4
******************************
Überall vsCode zu installieren ist doch auch keine Lösung.
******************************
Wieso nicht? Ist gut, schnell, zuverlässig! Funktioniert! Läuft hier auf jedem Blech.
Ich nutze auch gern die ISE. Ich muss mir nicht jeden Befehl mit allen Parametern merken oder ergoogeln, ich kann einfach drauf los tippen. Für die spontanen Aufgaben in der Administration ist das super. Vscode ist eher für Entwickler: jede Menge Plugins, viel Automatisierung möglich, Repositories angebunden, nett. Aber das ist eine Software, die konfiguriert und gepflegt werden möchte.
Das macht ein ganz anderes Arbeiten notwendig.
Du meinst etwa ein professionelleres Arbeiten? Das würde vielen "Scriptern" guttun. Nur weil man nicht programmieren kann bzw. gerne scriptet, muss man nicht immer alles "dreckig" machen. Man kann auch git nutzen und man kann auch vscode nutzen.
Eine Umstellung beim Arbeiten von ISE auf VSCode sehe ich beleibe nicht, wenn man die Features nicht nutzen will.
Ich schlage vor, bevor du über andere scharf urteilst, einfach mal zu lesen:
"Für die spontanen Aufgaben in der Administration ist das super."
Es geht um schnelle, kleine Aktionen. Wirfst du ernsthaft für kleine Aufgaben erst einmal die IDE an, schreibst ein Script, schiebst das ins Repo, … Bist du mal startklar bist, haben andere das kleine, spontane Script schon am Laufen.
Außerdem ist deine Antwort ziemlich arrogant. Du hat die Frechheit, über die Fähigkeiten eines Anderen zu urteilen, den du nicht kennst. Du sagst dass er unprofessionell ist und "dreckig" arbeitet. Gehts noch? Woher willst du das beurteilen können?
Es gibt immer mehrere Wege, eine Aufgabe zu lösen. Und bei kleinen Dingen ist eine Entwicklungsumgebung + GIT Workflow Overkill. Wenn man deinen Aussagen glauben kann, hast du mit deinem Ansatz bald ein Mega-zugemülltes Git-Repo, voll mit lauter kleinen, nie wieder benötigten Einmal-Spezial-Scripten.
VSC mit GIT ermöglicht einen super Workflow, aber nicht für jeden Zweck. Kleine Editoren haben auch ihre Daseinsberechtigung.
Und andere Tools als du zu verwenden, macht niemand unprofessionell.
Wenn man alleine in seinem Betrieb zuständig für das Scripting ist, mag ich Dir zustimmen – aber sobald es um die Zusammenarbeit mit anderen geht, führt an einer Versionskontrolle nichts vorbei.
Arrogant ist meine Aussage deshalb, weil ich immer wieder sehe, wie sich ITler in KMUs genau mit solchen Scriptchen irgendwelche maßgeblichen Funktionen bauen – das ist einfach kein guter Stil.
VSCode öffnen, Script erstellen und in das "kleine Scripte" Repo pushen dauert 2 Minuten mehr, maximal, als wenn man es einfach in Notepad++ hackt.
Hat jemand in dem Kontext Erfahrungen mit portable VSCode?
https://code.visualstudio.com/docs/editor/portable
(Also entzippen und Data Ordner Trick, anstatt Installation.)
Wenn das zusammen mit den Extensions funktioniert könnte das hilfreich sein.
Oder auch umgekehrt, wegen irgendwelcher Ungebundenheiten und vielleicht ausbleibenden Aktualisierungen?
Mir gefällt der Trend nicht gut. Fühlt sich so an wie diese "Externalisierung" des Edge Browsers, den man aber gefälligst als Systembestandteil fressen soll.
VSCode ist schon gut, insbesonders deshalb weil die ISE ja schon lange nicht mehr weiterentwickelt wird. Kann auch via WSUS und WPP aktualisiert werden.
Anstatt VSCode auf vielen Servern installieren, kann man sich auch einen sog. Admin- oder Entwicklungsserver installieren und dort alle benötigten Tools installieren. Übrige Lizenz vorausgesetzt.
Wir automatisieren sehr viel mit PS. ich verwende dazu die ISE mit ISESteroids (kostenpflichtiges Plugin), das kann von vscode in dem Umfang einfach nicht ersetzt werden.
Mir ist auch bei komplexen Scripts noch kein Fall untergekommen, der PS7 nötig gemacht hätte.
auch alle Module von MS basieren bisher auf PS5. wir verwenden außerdem einen Server zum Entwickeln, auf dem auch 99% der Scheduled Tasks ausgeführt werden.
Einige Server (zb RDS) können von dort nicht erreicht werden, da wird auf diesem Server entwickelt und dann auf den ausführenden Servern nur eine Kopie ausgeführt.
Alle wiederkehrenden Funktionen sind in einer selbst geschriebenen Library, die auch alle Unternehmens-Variablen enthält (Name des Maillservers, Shares, OUs etc). Diese Library wird von jedem Script eingebunden und man hat dann nur ein Script, wo man unternehmensweite Ändwrungen durchführen muss. Funktionen sind zb Email-Reports mit Company Branding, Konsolengröße anpassen, Random Kennwort setzen, eine Liste aller Firmenserver erstellen, Strings auf verschieden Muster testen usw.
Der schlimmste Anfängerfehler ist für mich, wenn jemand laufend gebrauchte Funktionen immer neu schreibt bzw in einzelnen Scripte hardcodet, wie der Name des Emailserverers usw ist.
Bei Umstellungen sind damit hunderte Scripts anzupassen statt ein Script, das von allen anderen eingebunden wird.
Aber stellt sich bei ISESteriods nicht auch irgendwann die Frage, wie lange es verfügbar ist?
Die letzte Version ist von 2019 und wenn ich versuche die Projektseite zu öffnen, meldet UBlockOrgin das etwas von "iyfbodn [ . ] com" nach geladen werden möchte und das steht auf einer Blockliste. Wollte es mir gerade am anschauen.
Was ist genau mit Library gemeint?
Eine selbstgeschriebene DLL in PS oder C#, ein Modul oder Dot Sourcing?
Unsere Admin-Accounts der Azure-Cloud sind mit security key abgesichert.
Eine Anmeldung mit z.B.: Yubi-Key ist unter Powershell 5 nicht möglich.
Das ist in Powershell 7 implementiert und zusammen mit VS-Code unsere eingesetzte Alternative.
Meine Skripte musste ich auch anpassen, da sie nun auf MS-Graph laufen sollen. MS-Graph ist wesentlich schneller. Dann musste ich halt auch zig Skripte anpassen.
das ist genau der Knackpunkt: man kann PS7 am Server verwenden, muss aber nicht. Mit Tricks (winget) kann man auch das Windows-Terminal auf einem Server ab 2019 installieren.
und für die Windows-Administration fehlende PS-Module kann man auch einfach mit PS nachinstallieren.
Mir gefällt auch die Windows-Admin-Konsole (WAC) recht gut und die kann die für die verwendeten Aktionen auch das Powershell anzeigen. Kann man dann kopieren und ausbauen.
Code entwickelt und testet man auf einer dedizierten Workstation, jedoch def. nicht auf dem Zielserver.
Bestenfalls führt man den fertigen Code auf einem gesicherten Jumphost remote gegen die Zielserver in der PowerShell-Umgebung aus.
Ich seh hier nicht den Bedarf an VS Code auf allen servern… 🤔
Doch,
wenn man sich einfach und schnell sehr sehr unglücklich machen will.
Letzlich muss auch jedes Script erst diverse Dev und Testsysteme durchlaufen bevor man es frei gibt.
Gruß
Meine Worte. Entwickelt wird auf einer separaten Maschine und das fertige Skript per Ansible, PowerShell DSc oder was auch immer verteilen.
Ich halte es auch für keine Lösung überall VSCode zu installieren. Ich halte meine Systeme schlank und installiere nur das nötigste, was für den Betrieb der Server-Anwendung notwendig ist (z.B. Web-Server inkl. Bibliotheken). So minimiere ich die Angriffsfläche auf das System, auch wenn ich zugeben muss, dass ein Angriff über VSCode o.ä. sehr konstruiert ist. Dennoch der VSCode-Editor kommt mit einer Schnittstelle daher, über die man einfach Module/Erweiterungen nachladen kann, wer weiß, ob das immer alles so sauber ist. Das möchte ich nicht auf einem Server haben.
Entwickeln tue ich daher auf einem Server überhaupt nicht. Ich nutze auf einem Server nur und ausschließlich die PowerShell-Konsole, um dort direkt Cmdlets oder Fünf-Zeiler auszuführen. Klappt wunderbar. Größere Scripte entwickle ich auf meinem Client, auf dem ich sehr wohl VSCode nutze. Entweder führe ich dann einzelne Script-Teile auf dem Server zum Testen aus oder ich nutze die Microsoft Dokumentation und lese dort Eingabe-/Rückgabewerte nach.
> … dass ein Angriff über VSCode o.ä. sehr konstruiert ist.
Vorsorglich, bevor hier vermutlich mitlesende Auszubildende Ihre Einschätzung für bare Münze nehmen: http://www.bleepingcomputer.com/news/security/malicious-microsoft-vscode-extensions-steal-passwords-open-remote-shells/
Ich habe hier für alle möglichen Aufgaben dutzende PS1 Skripte, habe die ISE aber so gut wie nie verwendet. Also zumindest hier kein großer Verlust.
Die Lösung lautet VS Code. Und die muss und sollte man auch nicht überall installieren! Die hat man maximal auf seinem Rechner, vielleicht noch auf seiner PAW oder einem Managementserver. Remote PowerShell ist ein Begriff?
> Remote PowerShell ist ein Begriff?
Ja, als Verbreitungsweg von Würmern. Ich habe es an anderer Stelle schon angesprochen: Bitte verantwortungsvoll posten im Hinblick auf mitlesende Auszubildende. PowerShell remoting beginnt genau hier: learn.microsoft.com/en-us/powershell/scripting/learn/remoting/jea/security-considerations?view=powershell-7.4
Wir nutzen schon lange keine ISE mehr. Ist eine total schlechte IDE.
VSCode ist nicht perfekt aber man kann gut damit arbeiten.
Wenn man am Server noch nachbessern oder gar entwickeln will (Testserver), dann ist VSCode auch gut geeignet. Am besten im User-Kontext installieren – nicht global/für alle User. Braucht nicht viel Speicherplatz. Die offizielle PowerShell-Erweiterung ist stark zu empfehlen, damit z.B. das Springen zur Definition funktioniert.
Das Problem mit den nicht vorhandenen PowerShell-Modulen ist tatsächlich lästig.
Unsere Lösung besteht daraus, beim jeweiligen Skript zunächst eine Routine laufen zu lassen, die prüft ob die benötigten Module installiert sind.
Wenn nicht, kann man sie (von Hand committet) installieren oder aktualisieren.
Mir gefällt VSCode überhaupt nicht, damit werde ich nicht warm. Bisher haben wir aber auch nicht die Notwendigkeit für eine neuere Powershell und machen eigentlich alles unter 5.1 und eben der ISE.
Wenn man VSCode nicht 'überall' installieren möchte: VSCode Server, https://docs.linuxserver.io/images/docker-code-server/
Was spricht dagegen, auf einem Rechner beide Powershells zu haben, also Version 5.x und Version 7.x und für die Entwicklung sowohl die ISE für 5.x als auch VSC für 7.x zu verwenden? Nur mit VSC in der 7er PS zu entwickeln birgt die Gefahr, dass man Skripte erstellt, die nachher auf einem Server mit vorhandener PS 5.x nicht korrekt laufen. Das muss man jedenfalls im Hinterkopf haben.
Auf einem Core-Server ließe sich z.B. VSC auch gar nicht erst installieren. Und gerade auf dem Core-Server ist die vorinstallierte Powershell 5 die Hauptumgebung, in der man sich als Admin bewegen und die meisten Dinge erledigen muss.
Was ich nicht empfehlen würde: auf einem *Server* die 7er PS parallel zur 5er zu installieren oder gar die vorhandene 5er durch die 7er zu ersetzen, wenn das überhaupt möglich sein sollte. Jedenfalls erscheint mir das dann doch etwas 'riskant'. Aber das muss jeder selber entscheiden.
Ich weiß schon: irgendwie müssen wir viele Server administrieren.
Aber den Komfort von Powershell&Co. noch dazu von anderen Servern erreichbar zu haben, erkauft man sich mit großem Risiko bei einem Sicherheitsvorfall.
Angeblich setzen mehr als 90% der Maleware Powershell ein.
Kein Powershell – 90% Maleware „ausgesperrt"/deaktiviert.
Dieses Risiko muss jeder für sich selbst abwägen.
Ich denke doch eher, dass die PS einfach deshalb so oft bei Ransomware-Angriffen genutzt wird, weil Sie schon vorinstalliert ist – wie viele andere legacy Programme in Windows aber auch. Warum also sollte man es sich mit legacy Programmen unnötig schwer machen.
Daher bin ich mir ziemlich sicher, dass die Rechnung "Kein Powershell – 90% Maleware „ausgesperrt"/deaktiviert." nicht aufgeht.
Nur ein weiteres Beispiel des Powershell-Einsatzes:
https://www.borncity.com/blog/2024/03/12/online-meeting-dienste-skype-zoom-google-meet-als-kder-fr-malware/
(Siehe Bild: "Diagramm veranschaulicht die Angriffskette")
Wie bereits geschrieben: Jeder muß das für sich selbst entscheiden – ich hab Powershell (und ISE), CScript, WScript,.. für unsere Systeme so gut wie möglich verhindert und verliere dadurch viel Komfort – hoffe aber dadurch ein wenig besser geschützt zu sein.
Ich persönlich versuche es die Powershell zu vermeiden. Sie ist für viele Dinge einfach zu langsahm.
Für wiederkehrende Aufgaben benutze ich mittlerweile das Visual Studio und schreibe Programme in C#. Die Syntax ist extrem ähnlich zur Powershell aber die Geschwindigkeitsvorteile von nativen C# Programmen ist riesig. Und wenn man Module für etwas benötigt bindet man sie ins Programm mit ein und ist nicht darauf angewiesen ob Powershellmodul XY vorhanden ist.
Nun, mit dem ISE bin ich noch nie warm geworden. Zu langsam, unübersichtlich und zu aufgepläht. Zumal wir meistens den Server Core im Einsatz haben. Klappt mit Exchange , SQL Server (außer man benötigt Reporting) und vielen weiteren.
Dafür gibt es einen Mangament Server und Management Client auf denen Notepad++ läuft. Syntax-Markierung und -vervollständigung inklusive. Ansonsten gibt es auch Get-Command.
Vielfach werden entwickelte Skripte gesammelt als MSI-Paket über den WSUS verteilt und dann lokal via Gruppenrichtlinie/Taskplaner entsprechend ausgeführt.
Adhoc kommt Remote-Powershell oder aber SSH und dann lokal Powershell/Windows-Shell zum Einsatz.
VSCode würde bei uns auf keinen Server kommen. Nicht ohne Grund wird die Server Core Variante bevorzugt. Also soweit wie möglich unnötige Bestandteile und Programmcode vermeiden um dann VSCode zu installieren?
.NET 6 und 7 (bzw. die Powershell dazu) ist IMHO eher eine Client-Angelegenheit, wo Programme wie Paint.NET, LogFusion, AutoCAD und viele andere darauf aufsetzen (da weniger mit Powershell der Zusammenhang). Bis einschließlich Windows Server 2022 haben wir kein gesonderes PowerShell installiert – auch nicht auf Clients. Bislang wäre mir noch kein Grund für den Wechsel vorgekommen… mal schaun was Windows Server 2025 in der Final-Version bringen wird? Stand jetzt war dort noch Powershell 5.x inkludiert. Lediglich Windows PowerShell 2.0 Engine wurde als abgekündigt markiert.
Was ist sonst noch zu erwähnen? Nun, wir setzen Powershell auch auf Linux ein – auch wenn dort so manche Befehle leider anders arbeiten oder fehlen. Bilde mir ein, auch da steht ganz vorne eine 5.
Zum Thema Malware – nun man kann mit Applocker dagegen ansetzen (braucht am Client aber Enterprise). Ebenso sind bei uns die Skripte mit Zertifikate signiert von der eigenen AD CA und nur die dürfen ausgeführt werden. Die Malware ist mit Sicherheit nicht von unserer AD CA signiert. Aufpassen bzw. eine Hürde sind Exchange Server, aber auch SQL und manche Dritthersteller (Citrix), die Powershell erweitern und nutzen. Da klappt dies nicht immer (also Powershell mit AllSigned).
Man muss aber anmerken, wenn der Hacker es schafft ein Skript lokal auf einen Server zu geben und auszuführen, dann hat man schlussendlich sowieso schon andere Probleme. Weil dann wäre es auch eine Batch-Datei, exe-Datei und anderem möglich. Hoffe mal niemand nutzt den Produktivserver um via Webbrowser im Web Sachen zu suchen und auszuführen? Malware mit Powershell ist eher ein Client-Thema… …und da geht immer AllSigned (und App-Locker).
AllSigned und Skriptsignierung bringt exakt überhaupt nichts, außer vielleicht, dass man sich in falscher Sicherheit wähnt. Das kann man auf x-verschiedene Weise umgehen, am einfachsten via Parameter der powershell.exe. Das nur mal am Rande.
Ja und nein. Für den Parameter brauchst du höhere (=administrative) Rechte – sprich powershell.exe muss exakt in so einer Sitzung gestartet werden. Zum Umstellen (Set-ExecutionPolicy) muss dies ebenso mit administrativen Rechten erfolgen. Hast du bereits administrative Rechte, na dann…
Ansonsten hilft noch App-Locker. Selbst mit administrativen Rechten kann dann ein nicht signiertes Skript verhindert werden.
Aber 100% unmöglich wird es nie werden. Sonst kannst irgendwann überhaupt nichts mehr richten im Problemfall. Ich mein, irgendwann verhindert man damit auch möglicherweise Rettungsversuche, Fehleranalyse oder normale administrative Tätigkeiten…
Nein, für den Parameter ExecutionPolicy braucht man keine erhöhten Rechte. Davon abgesehen gibt es noch mindestens 7 weitere Möglichkeiten, das zu umgehen, wenn ich mich richtig erinnere. Wir haben das verworfen, da es bestenfalls davor schützt, aus Versehen ein falsches Skript anzuklicken.
Edit: Mindestens 14 – siehe https[:]//www.netspi.com/blog/technical/network-penetration-testing/15-ways-to-bypass-the-powershell-execution-policy/
Also bei mir (uns) sehr wohl. Es kommt die Fehlermeldung:
Set-ExecutionPolicy : Der Zugriff auf den Registrierungsschlüssel
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell" wurde verweigert. Starten Sie zum
Ändern der Ausführungsrichtlinie für den Standardbereich (LocalMachine) Windows PowerShell mit der Option "Als
Administrator ausführen".
Ähnliches folgt beim Ausführen von Powershell mit Parameter Bypass. Wird noch vor Ausführung des Skriptes abgebrochen.
Ansonsten interessante Möglichkeiten, die mir jetzt nicht alle bekannt waren.