Warum PowerShell?

[daabm 1.353]

vor 4 Stunden schrieb cj_berlin:

Welches wäre denn von solch einem existenziellen Interesse?

 

Wenn man Runspaces nicht selber programmieren will, ist Foreach -Parallel sicher eines der interessantesten. Ist halt "einfacher", ein fertiges Cmdlet zu benutzen. Aber wie immer natürlich auch langsamer. Ich weiß aber nicht, ob Foreach überhaupt in einem Modul steckt oder ob das "core" ist.

[EmmKay 2]

Am 26.6.2024 um 18:07 schrieb daabm:

Linkservice https://www.thorsten-butz.de/7mythen/

In seinem Beitrag 7 Mythen über PowerShell 7 behauptet Herr Butz, dass der Filesystem Provider Schrott ist und deshalb die Hardcore User andere Methoden verwenden. Warum ist der Dateisystemanbieter Schrott und welche Alternativen werden verwenden? Kann die Aufgabe mit nativen PowerShell-Befehle und -Techniken gelöst werden, sollen laut PURE-01 Use native PowerShell where possible keine COM- oder .NET-Klassen verwenden werden. Außer es wird gemäß PURE-03 Document why you haven't used PowerShell dokumentiert, wenn man von der Empfehlung PURE-01 abweicht.

 

Gerne möchte ich PowerShell über mein Einstiegsniveau verstehen und anwenden.

 

Vielen Dank für Eure Erklärung.

[daabm 1.353]

Powershell abstrahiert viele Klassen des .NET Framework (die es unter der Haube natürlich verwendet). Leider sind manche dieser Abstrahierungen wie z.B. Dateisystem, AD-Cmdlets oder Arrays eher Snail als Rocket... Hardcore-User weichen deshalb auf [System.IO] aus (und auf [System.DirectoryServices] und [System.Collections]).

[NilsK 2.932]

Moin,

 

wobei unter "Hardcore-Usern" hier vor allem solche zu verstehen sind, die besonders performancekritische Aufgaben erledigen und ihre Skripte daher in diese Richtung optimieren müssen. Für alltägliche Zwecke ist das selten notwendig, dann haben die Erleichterungen, die die Cmdlets bieten, ihre Vorteile.

 

Die Cmdlets sind aber nicht "Schrott" in dem Sinn, dass sie was kaputtmachen würden.

 

Gruß, Nils

 

[cj_berlin 1.312]

vor 2 Stunden schrieb EmmKay:

Kann die Aufgabe mit nativen PowerShell-Befehle und -Techniken gelöst werden, sollen laut PURE-01 Use native PowerShell where possible keine COM- oder .NET-Klassen verwenden werden. Außer es wird gemäß PURE-03 Document why you haven't used PowerShell dokumentiert, wenn man von der Empfehlung PURE-01 abweicht.

Du hast aber auch den Anfang der PURE-Seite gelesen, gell?  

 

Die einzige Situation, wo es wirklich ars***rettend ist zu wissen, wie man Dinge ausschließlich mit PowerShell-Cmdlets löst, tritt dann ein, wenn Du dich als Skripter plötzlich unter Constrained Language Mode wiederfindest.

An der interaktiven Kommandozeile ist es in der Regel auch einfacher, Cmdlets als .NET-Klassen zu verwenden.

 

Beim Skripten jedoch spielen andere Faktoren eine Rolle:

• Performance und ihre Komplementärdisziplin, der Ressourcenverbrauch
• Portabilität
• Robustheit

und da ist man gut beraten, die dem ganzen zugrundeliegenden .NET-Techniken zu beherrschen.

[EmmKay 2]

vor 18 Stunden schrieb daabm:

Leider sind manche dieser Abstrahierungen wie z.B. Dateisystem, AD-Cmdlets oder Arrays eher Snail als Rocket...

Bei der Verwendung der CmdLets habe ich nie auf Geschwindigkeit geachtet. Da muss ich mir mal einen Test überlegen.

Die nativen Array finde ich auch eher umständlich und habe mich deshalb regelmäßig an Klassen aus dem System.Collections-Namespace bedient.

Ich dachte, dass Klassen aus dem System.DirectoryServices-Namensraum nur die ADSI-COM-Objekte kapseln und (leider) nur allgemeine Klasse wie DirectoryEntry oder DiretoryEntries zurückliefern und dass das ActiveDirectory-Modul hier Abbhilfe schafft. Ein Get-ADUser liefert mir erwartungsgemäß auch ein ADUser-Objekt zurürck. Den einzigen Vorteil bei der Verwendung von DirectoryServices-Klassen sah ich nur darin, dass ich Remote Server Administration Tools nicht installiert musste. In der Regel ist die ADSI-COM-Komponete überall installiert.

 

vor 19 Stunden schrieb NilsK:

 

Die Cmdlets sind aber nicht "Schrott" in dem Sinn, dass sie was kaputtmachen würden.

Ich hatte auch eher verstanden, dass diese CmdLets schlecht implementiert sind. Zum Glück gibt es in unserer Umgebung nichts, was performancekritisch ist.

 

vor 19 Stunden schrieb cj_berlin:

Beim Skripten jedoch spielen andere Faktoren eine Rolle:

• Performance und ihre Komplementärdisziplin, der Ressourcenverbrauch
• Portabilität
• Robustheit

und da ist man gut beraten, die dem ganzen zugrundeliegenden .NET-Techniken zu beherrschen.

Was meinst Du mit Komplementärdisziplin und Portabilität? Gibt es PowerShell-Bücher, die die zugrundeliegenden .NET-Techniken tiefer erklären oder muss ich ein Buch über das .NET-Framework lesen? Könnt Ihr mir weiterführende Literatur empfehlen?

[cj_berlin 1.312]

vor 4 Minuten schrieb EmmKay:

Bei der Verwendung der CmdLets habe ich nie auf Geschwindigkeit geachtet. Da muss ich mir mal einen Test überlegen.

Musst Du nicht. Viele haben sich die Arbeit bereits gemacht, hier ein Beispiel: 

 

vor 9 Minuten schrieb EmmKay:

Den einzigen Vorteil bei der Verwendung von DirectoryServices-Klassen sah ich nur darin, dass ich Remote Server Administration Tools nicht installiert musste.

Selbst wenn das der einzige Vorteil wäre, wäre es in vielen Situationen ein enormer Vorteil  Beispiel: Information aus dem AD wird in einem Login-Skript benötigt. Installierst Du dann auf 10.000 Clients AD-RSAT?

[EmmKay 2]

vor einer Stunde schrieb cj_berlin:

Musst Du nicht. Viele haben sich die Arbeit bereits gemacht, hier ein Beispiel: 

Vielen Dank. Dein Beitrag ist sehr aufschlussreich.

 

vor einer Stunde schrieb cj_berlin:

Beispiel: Information aus dem AD wird in einem Login-Skript benötigt.

Bei uns werden die Startup- und Login-Skripte nur in Ausnahmenfällen eingesetzt und benötigen keine zusätzlichen Informationen aus Active Directory. Grundsätzlich werden in unserer Umgebungen die Einstellungen per Group Policy Preferences konfiguriert. Aber Du hast recht, dann würde ich entweder das COM-Objekt ADSystemInfo oder die System.DirectoryServices-Klassen im Skript verwenden.

 

vor 1 Stunde schrieb cj_berlin:

Installierst Du dann auf 10.000 Clients AD-RSAT?

So eine große Umgebung haben wir nicht. Höchstens 300 Rechner. Die AD-RSAT sind sich nur auf die Admins-Clients installiert. 

 

[daabm 1.353]

vor 13 Stunden schrieb EmmKay:

Den einzigen Vorteil bei der Verwendung von DirectoryServices-Klassen sah ich nur darin, dass ich Remote Server Administration Tools nicht installiert musste.

 

Ich hab da mal ein Beispiel, wo DirectoryServices echt hilft. Klingt für viele sicher konstruiert, ist aber ein echter Praxisfall bei uns gewesen...

 

Aufgabe: Lösche in ~800 Remote-Domänen insgesamt etwa 30,000 Computer- und 30.000 User-Objekte (mengenmäßig sehr ungleichmäßig verteilt von <5 bis >1000).

Lösung in native Powershell single threaded: Iteriere über alle Domains (Get-ADDomain), ermittle alle Computer (Get-ADComputer) und User (Get-ADUser), iteriere dann über die Arrays und lösche sie (Remove-ADObject).

Lösung in multithreaded mit Runspaces und Directoryservices: Starte pro Domain einen Runspace-Job. In dem ermittle User und Computer dieser Domain mit paged searches (1000 Stück). Pro Resultset starte einen weiteren Runspace, der die Objekte löscht.

Der Zeitfaktor hatte ziemlich viele Stellen...

bearbeitet 5. Juli von daabm

[NilsK 2.932]

Moin,

 

vor 10 Stunden schrieb daabm:

Klingt für viele sicher konstruiert

 

Aber nein, wie kommst du darauf? 

 

Gruß, Nils

[cj_berlin 1.312]

vor 17 Stunden schrieb daabm:

Klingt für viele sicher konstruiert,

Das nicht, aber ich kenne einige, die länger benötigen würden, das optimierte Skript zu entwickeln, als die Laufzeit des unoptimierten gewesen wäre   

[daabm 1.353]

Das stimmt. Gehört für mich aber in die Kategorie "ich habe keine Zeit, meine Axt zu schärfen, ich muss Bäume fällen"

[Dukel 454]

In solchen Fällen stellt sich auch immer die Frage, wie Zeitkritisch ist das ganze.

Wenn es egal ist, ob das Script 2h oder 2d braucht, dann brauche ich ja keinen Aufwand in das Optimieren stecken.

[NorbertFe 2.032]

Evtl. Kommt dann aber manchmal noch der persönliche Ehrgeiz dazu, sowas technisch „schön“ zu lösen. Hängt halt von Aufgabe und Ausführendem ab. ;)