Jump to content

Warum PowerShell?


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Geschrieben
  Am 28.6.2024 um 11:20 schrieb cj_berlin:

Welches wäre denn von solch einem existenziellen Interesse?

Mehr  

 

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.

Geschrieben
  Am 26.6.2024 um 16:07 schrieb daabm:
Mehr  

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.

Geschrieben

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]).

Geschrieben

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

 

Geschrieben
  Am 4.7.2024 um 08:52 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.

Mehr  

Du hast aber auch den Anfang der PURE-Seite gelesen, gell? ;-) 
image.png.32e0ae881ea69db36ecb5a5f146beb62.png

 

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.

Geschrieben
  Am 4.7.2024 um 10:56 schrieb daabm:

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

Mehr  

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.

 

  Am 4.7.2024 um 11:02 schrieb NilsK:

 

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

Mehr  

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

 

  Am 4.7.2024 um 11:26 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.

Mehr  

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?

Geschrieben
  Am 5.7.2024 um 06:47 schrieb EmmKay:

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

Mehr  

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

 

  Am 5.7.2024 um 06:47 schrieb EmmKay:

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

Mehr  

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?

Geschrieben
  Am 5.7.2024 um 06:54 schrieb cj_berlin:

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

Mehr  

Vielen Dank. Dein Beitrag ist sehr aufschlussreich.

 

  Am 5.7.2024 um 06:54 schrieb cj_berlin:

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

Mehr  

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.

 

  Am 5.7.2024 um 06:54 schrieb cj_berlin:

Installierst Du dann auf 10.000 Clients AD-RSAT?

Mehr  

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

 

Geschrieben (bearbeitet)
  Am 5.7.2024 um 06:47 schrieb EmmKay:

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

Mehr  

 

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 von daabm
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...