BOfH_666

Kein Grund, sich zu entschuldigen ... ... alles gut ... es ist und bleibt ja Deine Entscheidung. Dann kann ich Dir aber nicht weiterhelfen. Für mich steht bei dem ganzen GUI-Thema für PowerShell-Code regelmäßig der Aufwand in keinem akzeptablem Verhältnis zum Nutzen. Ich bastel mir maximal noch einigermaßen hübsch gemachte HTML-Seite als Ausgabe-Medium aber das war's dann. Vielleicht wartest Du einfach noch bis morgen, wenn die Kollegen hier aus dem WE wiederkommen, ist eventuell einer dabei, der Dir weiterhelfen kann.

Darf ich fragen wozu? ... was soll dann damit passieren? Hast Du Out-GridView mal probiert?

"Sich noch nie angemeldet zu haben" unterscheidet sich aber von "vor mehr als 90 Tagen zuletzt angemeldet zu haben" ... Einfach mal ne entsprechende Suche starten. Gerade für das Thema Active Directory mit PowerShell gibt es quasi kein Thema, was nicht schon mal irgendwo behandelt wurde https://morgantechspace.com/2016/05/find-ad-users-who-never-logged-on-using-powershell.html https://webactivedirectory.com/2017/10/09/find-users-never-logged-into-active-directory/ https://www.itprotoday.com/compute-engines/use-get-aduser-determine-who-has-never-logged

Bei PrimalForms bin ich raus, aber wenn Du nur einen Account angezeigt bekommst, ist dieser eine Account wohl der einzige, der länger als 90 Tage nicht angemeldet war. Verändere doch die 90 einfach mal zu 10 oder 5 oder 2. Wenn ihr nicht alle auch am Wochenende arbeitet, sollten dann mehr Accounts ausgegeben werden. Wenn es Dir nur um eine "grafische" Ausgabe der Abfrageergebnisse geht, könntest Du auch Out-GridView benutzen.

Hmmm ... das mag jetzt vielleicht patzig klingen, aber meine ernsthafte Empfehlung wäre, es zu akzeptieren und sich wichtigeren Themen zu widmen. Wie Du offenbar schon selbst bemerkt zu haben scheinst, bist Du nicht der Erste mit diesem Problem und MSFT ist offenbar nicht gewillt am Status Quo etwas zu ändern. https://www.reddit.com/r/Windows10/comments/gf6txn/comment/fpv9d1y/?utm_source=share&utm_medium=web2x&context=3 https://docs.microsoft.com/en-us/windows-hardware/customize/desktop/customize-the-taskbar

Poste doch mal bitte Deinen Code! Vielleicht hast Du ja da einen Fehler drin.

USMT schon probiert? https://docs.microsoft.com/en-us/windows/deployment/usmt/usmt-overview

... mir ist als einziges Szenario die Verteilung der SCCM-Paket-Quellen geläufig - die sind halt ziemlich statisch. Ansonsten bin ich bei Dir.

Supi. Manchmal denkt man einfach ein bissl zu kompliziert. Ich versuche immer nach dem KISS-Prinzip zu arbeiten.

Du machst immer wieder die gleichen Fehler. Du brauchst dringend Grundlagen. Wir haben alles Nötige schon mal gepostet.

hmmmm .... na das nur wenn's nicht anders geht ... also wenn's eher hierarchische Daten sind ... aber das trifft ja in diesem Fall noch nicht zu.

siehe oben!

Es wär natürlich ne gute Idee, nicht nach "X" zu fragen, wenn Du eigentlich "Y" wissen willst. Wenn Du in der Spalte mit den Gruppen/Berechtigungen mehrere durch Trennzeichen getrennte Einträge drin hast, kannst Du die mittels "-split" in ein Array aufspalten und dann mit einer Schleife über dieses Array "drüber-iterieren". ... da brauchst Du keine 100 if's untereinanderzupacken. Edit: also sowas hier: $CSVInput = @' user,gruppen max.mustermann,"test1,test2,test3,test4,test5,test6" frau.mustermann,"test1,test2,test,3,test4" '@ | ConvertFrom-Csv -Delimiter ',' foreach ($Item in $CSVInput) { $GruppenListe = $Item.gruppen -split ',' foreach ($Gruppe in $GruppenListe) { [PSCustomObject]@{ User = $Item.User Gruppe = $Gruppe } } }

Die CSV müsste dann ungefähr so aussehen: user,gruppen max.mustermann,"test1,test2,test3,test4,test5,test6" frau.mustermann,"test1,test2,test,3,test4" Und mit https://docs.microsoft.com/en-us/powershell/module/activedirectory/add-adprincipalgroupmembership?view=windowsserver2019-ps kannst Du in einem Rutsch mehrere Gruppenmitgliedschaften für einen User konfigurieren.

Es wäre meiner Meinung nach einfacher, wenn es eine Spalte für die Gruppen gäbe und Du die einfach einem Rutsch den Usern zuweist.

Die Hilfe ist PowerShell eingebaut. Mit "Get-Help <cmdlet>" bekommst Du die Syntax angezeigt. Ausserdem kannst Du, wenn Du den Namen eines cmdlet getippt hast und nicht weißt, wie's weitergeht einfach ein "-" tippen und dann mit Tab durch die Parameter "blättern" oder in der ISE wird Dir, wenn Du den "-" eingibst, schon die Liste der Parameter aufgeklappt. Edit: Noch besser wäre, wenn Du VSCode für die Entwicklung von PowerShell-Code benutzt. Dort bekommst Du die meiste Hilfe.

Warum?

Es hilft meiner Meinung nach sehr dem Verständnis und der Lesbarkeit, wenn man die Parameternamen nicht weglässt. Nutzt man die "Tab-Vervollständigung" ist es auch nicht soo viel mehr zu tippen. Deine Code-Zeile $items = Get-ChildItem -recurse $folderpath "Neuer Ordner" ... würde dann zu ... $items = Get-ChildItem -Path $folderpath -Name "Neuer Ordner" -Recurse ... und ich packe Switch-Parameter immer gern ans Ende des Kommandos.

Ich würde Dir empfehlen, Deinen Code so explizit wie irgend möglich zu schreiben, keine Parameternamen wegzulassen, keine Aliase zu benutzen und so weiter. Das sollte Dir helfen, Deinen eigenen Code zu verstehen. Auch solltest Du, wenn Dein Code nicht das tut, was Du Dir erhoffst, selbst versuchen herauszufinden, warum das nicht so ist. Wenn Du Variablen erzeugst und füllst, lass Dir den Inhalt der Variablen einfach auf der Konsole ausgeben, das sollte Dich schon viel weiter bringen. Und die Methoden aus den Links, die ich Dir in dem anderen Thread gepostet hatte, machen dann den Rest. Wenn das nicht ein Fehler ist, der beim hier reinkopieren passiert ist, suchst Du in Deiner zweiten Code-Zeile nach einer (1) ganz bestimmten XML-Datei ("=.xml") und weist das Ergebnis einer Variablen zu. Eine Schleife über ein einzelnes Element, gibt im besten Fall einfach dieses eine Element wieder aus. In Deiner 4. Code-Zeile liest Du den Inhalt der Datei aus und speicherst ihn als XML-Objekt in der Variablen $xml. In der nächsten Zeile versuchst Du auf das XML-Object zuzugreifen, benutzt aber die falsche Variable - nämlich $xmlobject anstatt $xml. ... was ja nicht heißt, dass der Code fehlerfrei wäre ... ... kann ja auch nicht. Schau Dir doch bitte nochmal an, wie man ein PowerShell-Skript debugged!

... und ich mach noch ne Packung Treets auf ...

... oder auf PowerShell umzusteigen ...

Na ma kukn, wie's weitergeht. Wenn Du wieder etwas postest, bitte möglichst das komplette Skript.

Ich fürchte, da machst Du Dir ein bissl was vor. Es gibt in PowerShell verschiedene Ansätze, wie man Schleifen realisieren kann. Einmal die Pipe-Methode und dann die "Klassische" Schleifen-Methode. Schau Dir mal die Beispiele in den Dokus an, die ich oben verlinkt hatte. Die Dateinamen sollten dann in der Schleifenvariablen stecken, damit Du in jedem Schleifendurchlauf genau eine Datei beackerst.

Ich weiß gar nicht, wo ich da anfangen soll .... und das ist nicht böse gemeint. Du hast in den ersten 5 Zeilen 8 Syntax-Fehler. Wenn ich mich nicht irre, hatte ich Dir schon mal empfohlen, Dir als Erstes die Grundlagen von PowerShell im Speziellen und Scripting im Allgemeinen anzueignen. Du tust Dir selbst und uns allen keinen Gefallen, wenn Du das überspringst. Es heißt nicht umsonst "Grundlagen"!! ... alles andere baut darauf auf. Edit: z.B. ist Foreach nicht gleich Foreach .... https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/foreach-object?view=powershell-7.1 https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_foreach?view=powershell-7.1

Ich fürchte, Du haust da Einiges gehörig durcheinander. Wenn Du eine XML-Datei einliest und das auch als [XML]-Typ, dann solltest Du ausschließlich XML-Methoden für die Manipulation verwenden. Wenn Du eine "einfache String Ersetzung" machen möchtest, brauchst Du nicht explizit den XML-Typ erzwingen.