daabm 1.407 Geschrieben 28. Juni 2024 Melden Geschrieben 28. Juni 2024 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. Zitieren
EmmKay 2 Geschrieben 4. Juli 2024 Autor Melden Geschrieben 4. Juli 2024 Am 26.6.2024 um 16:07 schrieb daabm: Linkservice https://www.thorsten-butz.de/7mythen/ 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. Zitieren
daabm 1.407 Geschrieben 4. Juli 2024 Melden Geschrieben 4. Juli 2024 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]). 2 Zitieren
NilsK 3.019 Geschrieben 4. Juli 2024 Melden Geschrieben 4. Juli 2024 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 2 Zitieren
cj_berlin 1.455 Geschrieben 4. Juli 2024 Melden Geschrieben 4. Juli 2024 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? 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. 2 Zitieren
EmmKay 2 Geschrieben 5. Juli 2024 Autor Melden Geschrieben 5. Juli 2024 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? Zitieren
cj_berlin 1.455 Geschrieben 5. Juli 2024 Melden Geschrieben 5. Juli 2024 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? 2 Zitieren
EmmKay 2 Geschrieben 5. Juli 2024 Autor Melden Geschrieben 5. Juli 2024 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. Zitieren
daabm 1.407 Geschrieben 5. Juli 2024 Melden Geschrieben 5. Juli 2024 (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 5. Juli 2024 von daabm 1 Zitieren
NilsK 3.019 Geschrieben 6. Juli 2024 Melden Geschrieben 6. Juli 2024 Moin, Am 5.7.2024 um 20:36 schrieb daabm: Klingt für viele sicher konstruiert Mehr Aber nein, wie kommst du darauf? Gruß, Nils 1 Zitieren
cj_berlin 1.455 Geschrieben 6. Juli 2024 Melden Geschrieben 6. Juli 2024 Am 5.7.2024 um 20:36 schrieb daabm: Klingt für viele sicher konstruiert, Mehr 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 2 Zitieren
daabm 1.407 Geschrieben 6. Juli 2024 Melden Geschrieben 6. Juli 2024 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" 1 Zitieren
Dukel 466 Geschrieben 7. Juli 2024 Melden Geschrieben 7. Juli 2024 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. 1 Zitieren
NorbertFe 2.236 Geschrieben 7. Juli 2024 Melden Geschrieben 7. Juli 2024 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. ;) Zitieren
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.